Age of Invisible Disasters (2017) - <AUTHOR> https://blog.eutopian.io/the-age-of-invisible-disasters/ <comment><USER3> > The Therac-25 X-ray machine killed several people ... The reason? A race > condition.

The problem with the Therac-25 was _NOT_ the race condition. Complex devices will always have bugs, because humans haven't figured out a way to do perfect, bug-free engineering. The problem with the Therac-25 was that it wasn't designed to _fail safe_. The previous model had the same race condition bug, but it also had hardware monitors and interlocks which provided _defense in depth_.

The lesson of the Therac-25 _is not_ writing perfect software; the lesson is recognizing that humans make mistakes so anything remotely safety-critical needs to be designed to fail safely when - not if - mistakes/bugs happen.

<comment><USER4> Not being able to write perfect bug-free software is honestly a myth.

Short of bit flipping due to environmental conditions, it's more than possibleto get an algorithm and state machine perfect. Look at the old landline networks. Look at vending machines. It's just HARD. No one wants to pay for HARD.

Yes. Therac-25's problem did come from lack of defense-in-depth. That doesn't take away from the fact that Quality was sacrificed in the name of a cheaper production cost, and less time to market.

The easiest way to get people to be okay with shoddy things? Tell them it's impossible to do better. Microsoft took that route, so everybody drinks the kool-aid. Even people who should know better.

<comment><USER5> _Tell them it 's impossible to do better. Microsoft took that route_

Citation needed; where and when did they state this?

 _Look at vending machines._

Like the one at work which tells me to use exact change only, then accepts more money and still gives me the right change?

<comment><USER4> You know what, give me a few days to do some research if you're genuinely interested. I heard about it from a co-worker who did work with the early telcos way back when. He's passed away, but I never actually looked it up considering that co-worker's role as my mentor and deep insight into computing history that checked out before.

<comment><USER5> I am mildly interested, to the extent that it's any kind of specific, public Microsoft technical claim, rather than a piece of generic marketing hubris, or a rumour of something said in a closed-doors meeting of C-level people once upon a time.

(Re: Marketing disclaimer, e.g. the slogan in the UK " _You can 't get better than a Kwik-Fit fitter_", Kwik-Fit being a high-street chain of budget vehicle repair, I think analogous to something like Jiffy-Lube in the USA, it would be unreasonable for anyone to take this as a factual claim that "no better mechanics exist on the planet", excellent mechanics are more likely to work on racing car engines than routine oil and brake changes for near minimum wage, say)

</comment></comment></comment></comment></comment><comment><USER6> Many IT projects are failing because their budgets and deadlines are deliberately set too optimistically.

The reason for this comes from too sides: on the one hand, there is the client (either internal or external) who wants to have as many features for as little money as possible and who is many times not very good at judging if their demands are realistic. On the other hand there is the IT organization which has an incentive to comply with unrealistic targets.

If it is an external client, this unrealistic promise is the advantage over the competition that might get them the project. But I also see this happen regularly with internal projects where there is no competition between implementors. In that case the motivation is usually that IT management wants to have the consent of higher management to get this project started; they know that once a project has been going for a year or so, it won't be terminated if it's over budget or past deadlines. At the same time, if they would have tried to give realistic estimates too higher management the project might never have been approved.

<comment><USER7> Construction projects are the same. It seems like every week I read about another construction project that's far beyond its initial estimate. The difference is that a half-finished construction project is a gaping wound in the landscape, but a half-finished software project is just some code hidden in a corporate server. The incentive to finish construction projects is greater.

<comment><USER8> > The difference is that a half-finished construction project is a gaping > wound in the landscape, but a half-finished software project is just some > code hidden in a corporate server.

The difference is that missing deadlines in construction projects come with bigger monetary penalties (citation needed, based on the low penal damages I've personally seen in IT project contracts).

<comment><USER9> In a IT proje<t, the b1ame fa11s on the deve1oper who is then en<ouraged to work extra hours for free to make up for their own fai1ure.

</comment></comment></comment></comment><comment><USER10> The reason that software projects deliver so poorly in the corporate world is that senior executives and investors understand them so poorly that a large amount of recognition and attention goes to those who can "bullshit" rather than fix the problem.

This is particularly toxic, because often the senior executives and investors also have an interest in hiding the failure (avoiding personal accountability and avoiding write-downs on investment).

It is very hard to see how a culture of true reflection and learning can emerge in this environment.

<comment><USER11> I think the biggest problem is getting the requirements right (as much as possible) prior to the actual coding.

Many managers seem to think that they can easily change the requirements in the middle of the project.

<comment><USER12> It might be even the idea that (without an effort that matches or exceeds the implementation itself), you can "get the requirements right", i.e. that there is a point in time where the requirements are complete, fully understood and thoroughly specified.

<comment><USER13> Given the enormous scope of some of these projects I wonder if a prototype phase would help. Humans seem to have a hard time with conceptualizing and a slow, barely/non working and unscalable prototype might be worth the added cost/time. If it's part of the requirement gathering process with explicit expectations set that it's a prototype would it facilitate better requirements input? Naturally you'd have some people making assumptions about its fitness as a final product or MVP but (if a UI is involved) giant bright warning banners plastered all over might help with that.

<comment><USER14> The default state of a software prototype is to be shipped into production.

</comment></comment></comment></comment></comment><comment><USER15> The big software projects I've seen go bad don't feel analogous to the bridge failure mentioned in the article. It's more often poor project management, unclear requirements, and sub-par communication rather than a specific engineering failure.

Despite the lack of public post-mortems, poor project management seems to be widely recognized as a problem. But there isn't a clear cut solution. Agile promised to save us all but seems to be implemented poorly more often than not.

<comment><USER16> Agile (of the scrummy, we just meet sprint goals that we set type) is not a project management solution, it is saying "well this seems hard, so we're not going to do it".

Project management is happily alive. Thinking Agile in some way solves project management is insane.

Plan out your system, estimate the time to build it (you don't even need good estimates), execute ruthless change control. It's not hard, just takes discipline. Ruthless change control is the hard part. That doesn't mean saying no, it means saying "if you change things, it costs you schedule days".

If you want a clear cut system, iDesign has some good classes. Imo at least.

<comment><USER17> Once you finished planning out your system the requirements have likely changed. If they didn't you'll find out that you built something different from what the customer wanted once you're finished programming.

<comment><USER18> I don't think you're necessarily disagreeing with the parent post.

> Ruthless change control is the hard part. That doesn't mean saying no, it > means saying "if you change things, it costs you schedule days".

Just because software is dominated by soft costs doesn't mean that it's cheap to change requirements. That doesn't mean you can't deviate from your initial spec, it just means you have to charge the customer for changes that they want after you've already started development. Throwing away work just because it's "easy" to change software doesn't magically recover the time and money that you're already spent up to that point.

</comment></comment></comment></comment><comment><USER19> I'm not a project manager, and I most certainly haven't been involved in huge IT projects.

That said, from my POV it seems a lot of software related IT project failures is often correlated to two factors:

\- Doing too much at once. Like replacing 6 different existing specialized systems with a single new one.

\- Unwillingness to change the business procedures/workflow to cater to software.

The lure of the single do-it-all system seems strong with certain people. But at least in my experience, one could draw from software engineering and how good software is written as separated modules with well-defined interfaces at the boundaries. If you have multiple systems with good interfaces for data exchange, it's much easier to specialize where needed, and replace outdated or broken pieces.

The unwillingness to adjust the business procedures/workflow to software needs is a huge one. Complex software is fragile. By having complex rules in the business procedures you force the software to be more complex, thus invariably making the software more fragile. If business procedures were changed to be software friendly before the software is written/adapted, the software can be simpler and thus hopefully less fragile.

</comment><comment><USER20> It daunts me how much software is getting unreliable, but trying to shame people to hold them accountable is naive.

The root of the problem is the uncontrolled complexity of modern software products.

Because of this complexity responsibilities are diluted, most of your code is in your dependencies nowadays.

If you write a casual library, are you responsible if it is flawed and used in a critical operation? Can dependencies always be carefully audited?

<comment><USER21> It daunts me too, and reminds me of the early-days of commercial flight. I hope we'll have a similar "we cannot continue like this moment".

However, I don't think shaming is what this is about though. To me it seems the objective is to learn from mistakes, and for that we need to be honest about what happened, and it is going to be pretty hard to be honest if we tip- toe around who did what and why.

I also agree that complexity is a problem. But I don't think acknowledging this gives us any path forwards. I don't think going back to the 'good old days' is going to be a solution. I therefore see this leaning process as helping us figure out how to move forwards, and to provide a motivation to the industry as a whole. It is this industry-wide motivation that will be needed to address some of the systematic complexity issues.

I don't think this would be enough on its own (and implementation is a whole other question), but I think it could be a step in the right direction.

<comment><USER22> > It daunts me too, and reminds me of the early-days of commercial flight. I > hope we'll have a similar "we cannot continue like this moment".

The first citation of the words "Software Crisis" meaning the inherent difficulty of writing high-quality software in a predictable way was from a NATO conference fifty years ago: [https://en.wikipedia.org/wiki/Software_crisis](https://en.wikipedia.org/wiki/Software_crisis)

It is taking a long time for good practices to be discovered and win-out, and even when obvious improvements have been made, they're not necessarily used effectively.

I suspect a large part of the reason why the software industry isn't maturing at the same speed that other industries have had to, is that in software, failure is much easier to hide.

</comment></comment></comment><comment><USER23> A lot of the failures I experience at born from trying to solve business process problems with digitization, or digitization without ever asking if it's the right thing/way to do stuff. Another common problem is focusing too much on a particular set of business processes and forgetting that every IT system is part of a package of numerous IT systems that work together.

I live in one of the most digitized countries in the world. So we've naturally digitized payment for public transportation. When we did it, nobody questioned the taxation system, even though it was made in the 70ies and build around a public structure called "amter" that hadn't actually existed for many years when then system was build. We had also gone from 271 municipalities to 98 and their borders were part of the taxation too. So the taxation rules frankly didn't make any sense and they were needlessly complicated, yet they were digitized, as is. Naturally it was a disaster, it was even predicted by the technical team and the project leads, but nobody wanted to touch the taxation politically. It got fixed eventually, but it could have been several hundreds of million danish kroner cheaper if they had simply redone the taxation models for ticket prices before the digitization.

So that's one mistake, and a common one, both in the public and private sectors. The other common disaster is building systems for specific processes without looking at the bigger picture. Like a case working system that handles the welfare process for people who are sick. Except you forget that those citizens sometimes don't go through official communication channels, and maybe send a letter or an email to the wrong department, so you need to be able to add those documents to their digital case file. But that's not possible and neither is sending a notice to other systems in other departments which also deal with the same citizen. I'm guessing this last issue is bigger in the public sector than in private, because we often buy our software from companies that have very little actual domain knowledge outside of what their direct customers tell them, and the case workers they use for knowledge very often lack insights in the greater architecture of running 350+ IT systems together because they work with maybe 5 of them.

I mean, these things aren't deadly as the x-ray machine, but they've been happening for the better part of 25 years and nobody seem to have really learnt anything.

<comment><USER24> Oh, we have learned all those things as developers. It just seems that none of the decision makers have gotten any hint.

I'm honestly not sure why that is. I'm hesitant to only ascribe it to incompetence, because not everyone can be, but maybe we only hear about the failed project with bad decisions.

<comment><USER25> Why can't everyone working in a given field be incompetent? When Dr. Semmelweis discovered that surgeons washing their hands drastically reduced patient mortality, he was dismissed and ridiculed. I would say that 100% of those surgeons were objectively bad at their jobs and therefore "incompetent" in a narrow sense. Groupthink can cause everyone in a given field to converge on the same orthodox belief, and if that belief is wrong or dangerous, shouldn't they all be considered incompetent? Even today there are many pseudo-scientific fields where literally none of the practioners are objectively able to accomplish what they claim... and it's not at all obvious that project management is not among them.

</comment></comment></comment><comment><USER26> I wondered why an obscure post of mine was suddenly popular.

A clarification: The Therac-25 had an unfortunate race condition, what made this deadly was the conscious decision by the designers to REMOVE the physical safety interlock. They didn't consider modes of failure. The post says exactly this. Always consider modes of failure, you never know when some "other guy" is going to naively count on your work being 100% reliable. It's a system not a goal, as I like to remind people.

Some of you might enjoy some of my other stuff, particularly on security: [https://blog.eutopian.io/winning-systems--security- practitio...](https://blog.eutopian.io/winning-systems--security- practitioners-5.-resilience/)

The Tay Bridge disaster was important because: 1) Before it, we had several bridge failures in the UK. 2) After it we had almost none at all. Ever. 3) The report into the disaster was responsible for this improvement. It uncovered problems with: The design, the metal used, the way it was assembled, the maintenance regime, the project management and personal relationships and personalities of the people involved.

I'd lay money on the cause of the recent tragic bridge collapse in Italy being one of those already cited in that 140 year old report. It's all there.

Back to our own world...

When major IT projects fail, there is almost never a public enquiry, even when those failures are government projects, and even when they cost hundreds of millions of dollars/pounds. These failures are repeated regularly in government, and daily in the private sector.

Many of us who have been around a while have a (probably pretty good) understanding for why they fail, yet the lessons are not learned and there is little sign we are getting any better at all at not-failing. I suspect a bit of exposure to downside risk, or "skin in the game" as Taleb would call it, might improve things. Sometimes the medicine is hard to take.

</comment><comment><USER27> There's this book by Peter DeGrace and Leslie Hulet Stahl called Wicked Problems, Righteous Solutions. It describes all of these problems and others. It presents a number of very practical and proven solutions.

The book was published _28 years ago_ , in 1990.

We use words like science and engineering in conjunction with others like computer, programming, and software. And yet there's nothing scientific about how we don't learn from mistakes already made decades ago. And how we keep reinventing "engineering" best practice and call them new names.

<comment><USER28> You've probably heard the line "complexity is the enemy", or perhaps even its full form: "complexity is the enemy _of reliability_ ".

You may not know its provenance: _The Economist_ , Volume 186, January, 1958, or 60 years ago:

[https://books.google.com/books?id=aDsiAQAAMAAJ&q="complexity...](https://books.google.com/books?id=aDsiAQAAMAAJ&q="complexity+is+the+enemy+of+reliability"&dq="complexity+is+the+enemy+of+reliability"&hl=en&sa=X&ved=0ahUKEwjVw5S5o4vdAhUCF6wKHV8bDckQ6AEIKDAB)

I've been trying unsuccessfully to secure a copy of this article for some years. PDF preferred, dredmorbius<at>protonmail<dot>com if anyone should have access.

<comment><USER29> If you're willing to pay $100 to secure a copy, you can probably read it in the Economist Historical Archive.

[https://shop.economist.com/products/the-economist- historical...](https://shop.economist.com/products/the-economist-historical- archive#)

<comment><USER28> Not.

My research trove exceeds 10k items. I don't have a $100/item, or even source, budget.

</comment></comment></comment></comment><comment><USER30> > _If you find yourself on a failing project, squandering tens of millions of > pounds and hundreds of man-years of talent, pause for a moment. Think about > the fact that almost 140 years ago, civil engineers stopped building bridges > that fell down. They stopped building them because the failure of one bridge > was laid bare so publicly._

> _Think about the fact..._

You can think all you want, but it's unlikely to do anybody any good. Sometimes the fault for a failed project lies squarely with the engineers, but this is not at all the usual case. The people who are most responsible for failed software projects is _management_ , and not just engineering management, but the people who engineering management reports to.

And the biggest problem management has is not simply lack of understanding of the nature of software development projects, but, often, a profound lack of interest in learning.

I don't know what to do about that.

</comment><comment><USER31> Kind of weird that they used a novelty fake newspaper front page to illustrate this. The Scottish Scribe is a book of mocked-up newspaper front pages attempting to show how a modern tabloid might have dealt with historic events.

</comment><comment><USER32> > I count £20b in failed IT projects over the last decade alone.

It's hard to grasp the sheer _scale_ of government. This article does a good job of juxtaposition in the case of the magnitude of engineering failures, but I want to add on that $20 billion is chump change when it comes to waste. The military sector alone plowed through $700 billion last year to accomplish the task of robo-killing brown people. The entire federal budget was $2 trillion. Stop and think about those numbers for a bit.

There are 2.8 million civil servants in the US, and 2 million military personnel. $2T divided by 4.7 million means _every single government official_ is responsible for roughly $425,000 of your tax dollars. This includes postmen and every boot camp trainee.

Obviously only a fraction of these people are making decisions. So you can add zeroes to that number when you want to consider how much power the actual decision makers have. These decision makers are human, and humans are wont to see themselves as kings of their domain, and what is a king's job but to squander money squabbling over fiefdoms.

The sheer, mind-boggling scale of systems of government, all of them, from your homeowner's association to your neighborhood council to your city government to your state government to the national government to international governmental organizations like NATO and the UN, isn't even the most interesting aspect to consider here.

A more amazing thing to think about is how they manage to get anything done at all. But that's not even the biggest thing.

The biggest thing is that there is nothing new about this state of affairs. Civilization was built like this, thousands of years ago.

It's an admirable goal to want to get rid of waste in government. But that's an untamable firehose. You won't even get laughed at for a proposal to save $20b of tax money. They will look at you, decide whether you're going to look good on TV, maybe put you up in front of a camera if you're really really really really lucky, and everything you spent your whole life learning to finally try to do will get swept into a political capital generating exercise for a _local_ politician. Thanks, try again next life.

Governmental cruelty knows no bounds.

</comment><comment><USER33> There is currently a huge problem with the Bulgarian Electronic Trade Register [0]. The register stopped working two weeks ago and is still not online [1].

It holds all company ownership data and a lot more. Right now there is no way to register a company in my country, as well as making any changes to existing companies ( e.g. changing manager, shareholders, etc. ). It is one of the most important set of data for an EU country.

The original problem ( leaked by the government ) is that a 4 of the RAID5 disks broke down, but it is still a mystery why recovering the data takes more than 2 weeks.

0 : [http://brra.bg](http://brra.bg)

1 : [https://bivol.bg/en/classified-information-and-human- error-c...](https://bivol.bg/en/classified-information-and-human-error-caused- trade-registers-collapse.html)

<comment><USER24> It's amazing that 4 R5 disks could break down in the first place. Apparently they had triple redundancy and STILL managed to make it fail.

Though I bet it was just nobody ever checked if the disks were still working.

<comment><USER34> What didn't help was that the backups were stored on the same LUN as the production database.

<comment><USER35> Ouch.

There is a reason my backups are held on a separate machine in a separate building (and also on large external encrypted drives that leave site everyday).

Sometimes you learn these the hard way.

</comment></comment></comment></comment><comment><USER36> I once read on Hacker News that in the future, the C-level people all need to be very strong in IT as any company or organisation nowadays is so much reliant on IT.

It's also the message of the Phoenix Project book, which I did like.

The problem I have noticed is that although management does understand their businesses, it's easy to bullshit them when it comes to IT. And they let it happen because they are not into IT and they don't grok it. They would never treat other projects like this the same way when they would totally understand it.

I especially notice that as I read what higher management layers write about projects or effort, it's high on fluffy 'visionary' words but low on actual actionable vision that would help me to make every day decisions on what to prioritise.

I believe that the simple reason why IT projects fail is because of very mundane basic things.

But those are not sexy to write about. To me it's all about:

\- Why are we doing this? \- How would you define succes and failure for this project \- Who is responsible for what / contact person \- How do we work with each other and detail this \- What are the guiding principles \- How do we assure quality \- How do we assure timely delivery \- What stuff do we need, gear, licenses, etc. \- P R E P A R A T I O N - do your homework, investigate things beforehand before you make choices.

I can go on and on. And it may bore you. But I think there is actually no true complexity involved in all those failing projects.

There is not something really special to IT projects. I wonder if we do pretend there is something special to them because we ourselves want to feel important in some sense.

<comment><USER37> I don't disagree with you at all, however we (in IT) also bear responsibility primarily in the following areas: 1\. IT don't really understand business. Often we think we do - more so than the business does - and that hubris often blinds us to the real issues that the business neeeds to address. This can be resolved through use of boring old enterprise architecture (real E, not just tech E), and business analysis. Actually making the effort to understand. Sadly most EA's and BA's aren't. These are specific skills and they relate primarily to people and process rather than technology. 2\. Technology is largely overrated. I know that is likely to be an unpopular opinion. Sorry, not sorry. I am an Enterprise Architect by training and by trade. I've worked on several multi-hundred million dollar programs. I can promise you that in my experience, had every single tech decision been flipped or changed, the difference in outcome would have been +/\- 10% at most. Projects are not won and lost on technology. Completely missing or misunderstanding requirements, miscommunication, poor program financial management, overestimating the business' capacity for change - these (and more) are the things that are more often than not likely to make the difference between success and failure. 3\. You are not Google. Or Apple. Or Spotify. Or Amazon. Unless you are one of those companies. But if you're an energy company or a financial services company - then no. Just no. Your business is largely conservative, managed (ideally) by risk averse managers, invested in by people who want a certain return. Your industry is highly regulated and there are things you have to do, that you don't control and you do them whether the timing is good or not, at the expense of things that you do want to do. So stop fucking kidding yourselves and realise what you actually ARE, and cherry-pick & adapt those things that are likely to work for you.

It's not like we collectively don't know this stuff. Let's stop drinking our own kool -aid. And for those of you that do work for cool companies or startup disrupters I'm really happy for you. For the rest of us, technology is not the centre of the universe. Appreciating that difference is important.

And yes, I know I've missed valid arguments swung the pendulum a bit far the other way. It's deliberate. We are in danger of disappearing into our own navels.

<comment><USER38> My last bank was a staid conservative heavily regulated business that lost my custom because they were so poor at technology.

My electricity supplier is close to loosing my business in part because their web site won't accept my meter readings.

I'll be basing my decision on what car to buy my wife at least partly on whether it works with my iPhone. If it doesn't then you won't be on the list.

And on and on. We increasingly interact with businesses through technology, if they can't get that right then they are going to suffer. They can't get it right unless they take it more seriously right up to board level.

<comment><USER37> "Conservative" in this context doesn't mean how they interact wi H customers but how they run their business (of which customer interaction is a part). The tech you are talking about is the visible bit of the iceberg. Work in the back office for any length of time and you'll know what I'm talking about.

</comment></comment></comment></comment><comment><USER39> There is some work on this : [https://spectrum.ieee.org/static/lessons-from-a- decade-of-it...](https://spectrum.ieee.org/static/lessons-from-a-decade-of-it- failures)

But... there are three key problems.

1) The time scales are long - in my experience big project failures are on a >5 year time scale (because - big) I think proper studies will need to run >10 years, and that's a big ask for any academic or team.

2) The costs are borne by one set of stakeholders (IT) the benefits are accrued by another (next IT). Why invest to help your successor? No one is going to thank you, also you will likely be sacked faster! There is no board level education or knowledge about this. The only source of information that could convince boards that this is the right thing to do would be Mckinsey/Bain/BCM and those _& &^^"! will never, every say this because it's the right thing to do and they are evil. (prove me wrong!)

3) What do you measure? The field is immature, it's not clear what the right inputs to check are - or what the right way to estimate the outputs are. So we need to do a lot of work now to set up the definitive studies.

I have an anecdote : there is a thing called The FEAST hypothesis [http://users.ece.utexas.edu/~perry/work/papers/feast1.pdf](http://users.ece.utexas.edu/~perry/work/papers/feast1.pdf) I was a user of one of the studied systems, and I was curious about the study. I discovered that it hypothesised that development of big systems slowed as they got more complex and the data from the system I used was one of the points that confirmed this. I examined change control documents and discovered that the development of said system _had* slowed before the end of the study, but then it had reaccelerated, a whole load of "robots" had been implemented by business units consuming the system and these had not been reported in the FEAST study (IT was largely unaware) the robots started causing problems, policy changed, they were insourced, on platform development took off.

We need

\- 5 year major international project to develop the art to support this \- legislation that mandates system development information is stored up front and in a shared place. \- legislation that mandates regular reviews that determine certain information that is signed off by an engineer. \- 20 year massive project to use above information

I am not optimistic.. We can't even prove that XYZ better than agile..

</comment><comment><USER40> There are many problems with software projects but a fundamental one often not raised is it is hard to say "this bridge will be built using this quality steel and this much effort and time" when there are ten other companies, all looking from the outside as convincing, saying we will donit in half the time for half the cost.

I am not sure i have too many answers. But having a genuine profession that is required by law to sign off on any life-critical software seems a sensible starting point

</comment><comment><USER41> > Think about the fact that almost 140 years ago, civil engineers stopped > building bridges that fell down. They stopped building them because the > failure of one bridge was laid bare so publicly.

Yes, but how many bridge projects failed in the last 140 years because of cost overruns/missing deadlines which is a more direct analogy for most of the arguments in TFA.

And I'm guessing we're just talking about the UK since earthquakes have taken down a bridge or two in my lifetime...

<comment><USER28> Exceptionally good point. Confounding _failure of a project to deliver_ wwith _the catastrophic public failure of that project 's deliverables_ is a truly _extraordinary_ category error.

I was reading just recently of a failed megaproject, the Nicaraguan Canal. Forecast costs range from $40 - 100 billion, though I cannot find a report of actual expenditures.

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

Contrast this with actual _engineering_ failures, such as Fukushima or Banqiao. This is an apple-juicer to oranges comparison.

[https://en.wikipedia.org/wiki/Fukushima_Daiichi_nuclear_disa...](https://en.wikipedia.org/wiki/Fukushima_Daiichi_nuclear_disaster)

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

</comment></comment><comment><USER42> Poor managment doesn't always stem from ignorance or lack of understanding of how SW works. Sometimes it emanates from pressure to deliver within very tight timelines for the sake of survival of business or standing up to the competition in the market.

I have seen the best managers giving into ridiculous deadlines at the time of project onset just because they know that there is no other option.

</comment><comment><USER43> In this post, Bertrand Meyer made a similar claim taking the airplane industry as a reference.

"When Will We Learn? Every major software incident requires a thorough and public analysis."

[https://cacm.acm.org/blogs/blog-cacm/227943-when-will-we- lea...](https://cacm.acm.org/blogs/blog-cacm/227943-when-will-we- learn/fulltext)

</comment><comment><USER44> > _Think about the fact that almost 140 years ago, civil engineers stopped > building bridges that fell down._

It was written last year, but it looks like a weird sentence this year:

[https://en.wikipedia.org/wiki/Florida_International_Universi...](https://en.wikipedia.org/wiki/Florida_International_University_pedestrian_bridge_collapse)

[https://en.wikipedia.org/wiki/Ponte_Morandi#Partial_collapse](https://en.wikipedia.org/wiki/Ponte_Morandi#Partial_collapse)

It's even not that unusual. In [https://en.wikipedia.org/wiki/List_of_bridge_failures#2000–p...](https://en.wikipedia.org/wiki/List_of_bridge_failures#2000–present) I counted like 150 bridges collapses in the since 2000.

<comment><USER45> Back then (to quote another comment here): "a quarter of all the bridges of any type built in the U.S. in the 1870's collapsed within ten years of their construction."

Metallurgy was primitive, and there were no x-rays available to find hidden cracks formed during the manufacturing process.

</comment></comment><comment><USER46> The book he wants has been written. It's called The mythical man-month, by Fred Brooks. It does a post-mortem about what went wrong (an what went well) on the development of an IBM OS.

I think it contains today mostly stuff everybody knows, so it had a lot of impact on our profession. Not on the coding part, but very deeply on the management part.

</comment><comment><USER28> A (justifiably dead) comment mentions the, erm, case, of the FBI's Virtual Case File,a $170m project killed in 2007.

[https://web.archive.org/web/20130729205010id_/http://itc.con...](https://web.archive.org/web/20130729205010id_/http://itc.conversationsnetwork.org/shows/detail1688.html)

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

[https://web.archive.org/web/20051201114736/https://www.spect...](https://web.archive.org/web/20051201114736/https://www.spectrum.ieee.org/sep05/1455)

</comment><comment><USER47> Things makes me think about the poor woman who was killed by a "self driving car".

If the software had acted as expected she would have been alive. If self driving cars become popular, coding mistakes will kill more people.

(Yes, they had wilfully disengaged the built in automatic breaking feature of the car in order to allow their software to control it, and the human safety engineer riding in the car, was not paying attention to the road (also because the safety egineer blidnly trusted the software runnign the car) were factor as well)

<comment><USER48> > also because the safety egineer blidnly trusted the software runnign the car

My understanding is the opposite. Uber's software was generating a lot of false breaking events so they set it up so it wasn't controlling the breaks. Drivers were trying to gather evidence about the triggers for these false events. That created this perverse situation where the software correctly identified it should have braked, but the only action it could take was to raise an alert, distracting the driver at a critical moment.

</comment></comment><comment><USER49> Just as big as failing safe, is not failing silently.

Thats the another key from the Therac-25 - it failed mostly silently - <USER2> displayed an strange message that didnt make any sense, and there was no obvious detection of a failure.

Software need not be bug free - for example, there is a reason we still include hardware watchdogs on embedded devices, and its largely because the watchdog is cheaper than bug free software, and will provide the same quality of service.

</comment><comment><USER50> The biggest errors I've seen is where people buy COTS for their core business. Which is usually a mistake is IT is a main driver for your business in some special circumstance.

Also if you do go COTS and don't do the business change to fit the product. Trying to make COTS work your way is always so so so bad.

<comment><USER51> It depends on the phase your business is in. For the beginning using standardized stuff that you buy ready made can be a real time saver, and time is usually in short supply. Once you achieve a certain scale and you can afford to do it you can usually save substantially and scale up further by doing something more customized.

Starting off with a complete custom set-up for your core is another opportunity for premature optimization to creep in.

<comment><USER50> I've seen this happen where a mature business starts to functionally decomposes their business down to what they do and how they deliver. They then go out and buy products that do those things and link them in a chain with a DB. But each one of those is short about 10-20% in all the used to haves and nice to haves.

So what then dawns on the business is they realize that the missing 10-20% was part of the business that was really important and they have dropped serious money on a bunch of products. And really all they needed to do was better understand themselves and build their own business infrastructure.

But what you are saying about speed definitely rings true. But it's important to note IT failures that happen to new businesses are more or less written off as total business failures Usually resulting in the business going to the wall.

</comment></comment></comment><comment><USER52> A bridge falling under a train and a non-delivered project don't really have much in common. Major engineering projects keep being delivered very late or scrapped altogether, not that software is altogether different in this regard.

</comment><comment><USER53> Using the collapse of an Italian bridge as an example of the kind of disasters that happened in the past is somewhat unfortunate, although the author couldn't have known.

</comment><comment><USER54> We _are_ seeing bridge collapses again. Genoa last week. Florida last month.

</comment><comment><USER55> When I see Therac it reminds me of Theranos - another medical device with that went into production with serious issues.

<comment><USER51> It is unfair to the makers o the Therac to compare them with Theranos.

</comment></comment><comment><USER56> This is not the first time bridges have been used in comparison with software development.

From Programming Pearls, Section 7.3 [Safety Factors], by Dr. Jon Bentley, which reproduces Vic Vyssotsky's advice from a talk he has given on several occasions.

"Most of you'', says Vyssotsky, "probably recall pictures of `Galloping Gertie', the Tacoma Narrows Bridge which tore itself apart in a windstorm in 1940. Well, suspension bridges had been ripping themselves apart that way for eighty years or so before Galloping Gertie. It's an aerodynamic lift phenomenon, and to do a proper engineering calculation of the forces, which involve drastic nonlinearities, you have to use the mathematics and concepts of Kolmogorov to model the eddy spectrum. Nobody really knew how to do this correctly in detail until the 1950's or thereabouts. So, why hasn't the Brooklyn Bridge torn itself apart, like Galloping Gertie?

"It's because John Roebling had sense enough to know what he didn't know. His notes and letters on the design of the Brooklyn Bridge still exist, and they are a fascinating example of a good engineer recognizing the limits of his knowledge. He knew about aerodynamic lift on suspension bridges; he had watched it. And he knew he didn't know enough to model it. So he designed the stiffness of the truss on the Brooklyn Bridge roadway to be six times what a normal calculation based on known static and dynamic loads would have called for. And, he specified a network of diagonal stays running down to the roadway, to stiffen the entire bridge structure. Go look at those sometime; they're almost unique.

"When Roebling was asked whether his proposed bridge wouldn't collapse like so many others, he said, `No, because I designed it six times as strong as it needs to be, to prevent that from happening.'

"Roebling was a good engineer, and he built a good bridge, by employing a huge safety factor to compensate for his ignorance. Do we do that? I submit to you that in calculating performance of our real-time software systems we ought to derate them by a factor of two, or four, or six, to compensate for our ignorance. In making reliability/availability commitments, we ought to stay back from the objectives we think we can meet by a factor of ten, to compensate for our ignorance. In estimating size and cost and schedule, we should be conservative by a factor of two or four to compensate for our ignorance. We should design the way John Roebling did, and not the way his contemporaries did -- so far as I know, none of the suspension bridges built by Roebling's contemporaries in the United States still stands, and a quarter of all the bridges of any type built in the U.S. in the 1870's collapsed within ten years of their construction.

"Are we engineers, like John Roebling? I wonder.''

<comment><USER45> All that verbiage was the cover story, after the fact. The problem was flutter - and humans have known that can happen since there were flags. The bridge was severely under-engineered, just omitting what had been standard components (including trussing under the bridge) for such bridges for a long time, to save money. There was nothing unpredictable about the result.

</comment></comment><comment><USER57> This entire article and discussion is based on a fake headline and a false premise.... there are far fewer disasters of these kinds than there were because we learned from them. There are far fewer system failures of most technical kinds as well.

"Siri didn't immediately play the right song from my Infinite jukebox at my voice command" is not a bridge collapse. "My online banking was down for an hour" is not near the inconvenience of not having banking available every evening and night before online.

One saving grace is that truly incompetent software projects of any size never make it off the ground (or stay up long enough to be relied on).</comment>


What do you think is the hottest programming language of 2014? - <AUTHOR> https://epoll.me/ACRdC_Yg9pc/what-do-you-think-the-hottest-programming-language-of-2014-is

<comment><USER2> Why isn't Rust on that list?</comment>


Our path to $1M in Sales (2013) - <AUTHOR> http://wiwillia.com/post/41810471731/our-path-to-1m-in-sales?hn=true <comment><USER2> What I'm curious about is what that original MVP looked like. How did the cash collection get sorted out? Was it just dumping it into a Stripe account, and then any refunds for situations where there weren't enough orders would be manually processed?

Also, I wish the article talked more about the affiliate program. A while back, I remember a distinct uptick in the number of stories and content marketing spam hitting various startup forums around how people were making it rich with Teespring and Facebook ads. It was very obvious it was the next fad in the affiliate marketing space.

How much of that was a conscious marketing push by the Teespring crew vs. just something that sprung up on its own? The "get rich quick" crowd was all over it, and I can't help but think that was a big leader in initial growth as well as content that drove organic traffic back to them (perhaps one step removed via an affiliate).

<comment><USER3> > Was it just dumping it into a Stripe account, and then any refunds for > situations where there weren't enough orders would be manually processed?

I'd love some confirmation on this too. I had a protracted email exchange with some members of the Stripe support team which I didn't find favourable. Mainly because they didn't understand my actual business. But it lead me to choose a competitor who was actually happy to work with me.

Their main issue was the amount of refunds that I may be getting due to the business model. At the time of the email exchange I hadn't even started to operate!

So with respect to refunds. What's the operating procedure? If you get too many, do they suddenly close your account? In my instance, if my current provider were to close my account. I'd be out of business, instantly!

That's why I didn't go with Stripe. Which is a shame, as I wanted to use them, as I heard some good things about them.

Thanks

<comment><USER2> Out of curiosity, what did you go with in the end?

It almost seems like some sort of escrow type service is more appropriate. Is there anything like that with a similar developer-friendly platform/API like Stripe to facilitate crowd-funding? I'd honestly be surprised if there wasn't at this point.

<comment><USER4> I built an online registration service. We needed to be able to do refunds easily (free) in case the event was canceled. We used WePay because at the time, they were the only company that offered free refunds.

WePay has been through several incarnations/pivots over the years, not sure how they are now as I've moved onto another business now.

<comment><USER3> Thanks for the suggestion about WePay. Sent them an email requesting more information.</comment></comment></comment></comment></comment>


First impressions of the Apple Watch - <AUTHOR> http://bilue.com.au/using-the-apple-watch/

<comment><USER2> The previous article on that site is essentially an announcement that they (they're a consulting company, I gather) have developed a big, early Apple Watch app: [http://bilue.com.au/helping-woolworths-innovate-on-the- apple...](http://bilue.com.au/helping-woolworths-innovate-on-the-apple-watch/)

<comment><AUTHOR> Yeah, we're a consultancy based in Sydney. Woolworths is a big supermarket chain down here in Oz and we've done an Apple Watch app for them.

<comment><USER3> I do remember seeing the Woolworths logo in the background of the keynote and checking that it really was the Woolworths Australia logo. Seems Wesfarmers missed a trick - congrats on landing that gig! :)

If you're not still under NDA, are you able to say if that means the app was developed without access to Watch hardware? (I assume that's the case from the first impressions of Apple Watch post.)

</comment></comment></comment><comment><USER4> For me the review stopped being relevant when the author mentions being a Pebble watch owner. Ie I don't personally relate to people who already own a smart watch (to me a pebble watch is geekery for the sake of geekery).

I'm more curious about the impressions of someone who has no smartwatch and doesn't think they need one but are happy to give it a whirl and see how useful they find it after a week.

<comment><USER5> > _I don 't personally relate to people who already own a smart watch (to me a > pebble watch is geekery for the sake of geekery)._

I'd argue Pebble (specifically, the Pebble Steel) is the opposite of your impression.

It's life altering (lets you leave other electronics in your pocket or bag and manage notifications w/o geeky hard interruptions). It's practical (week+ long battery so you can wear it 24/7). It's not particularly more expensive than other digital watches with brushed stainless steel cases and leather bands. It is not recognized on the street as a "smart watch".

<comment><USER4> Fair enough.

What I meant is that Pebble is probably bought by early adopters. Ie people who _want_ to have a smart watch.

I'm more looking for experience of those who don't feel like they need one but tried it nonetheless.

</comment></comment></comment><comment><USER6> I think the biggest issue with the Apple Watch is clearly the battery. Recharging my watch everyday seems problematic. Especially when keeping in mind that the "17 hours" will probably melt down and soon become barely enough to last the whole day.

<comment><USER7> You probably charge your phone everyday though, and I know my dad never sleeps with his watch on his wrist and isn't the only one with this habbit. So why couldn't you charge your watch every night ? Also, charging your apple watch is probably going to be wireless in the coming years, so it'll be as easy as setting it on your night stand before going to bed.

As for the battery, I have no idea how the hardware is set up, but it's the same for many many watches? Don't you have to change the battery every (few) year(s)? I'm obviously not talking about the fancy Rolex style mechanisms that power the watch using your wrist's kinetic energy

<comment><USER8> I think a lot of it depends on how accustomed you are to wearing a "traditional" watch but still, I've had a similar experience with my smart watch (Moto 360).

Compared to the watches I stopped wearing probably 5-10 years ago, sure, the battery is terrible but as I mentioned, I had gotten out of the habit of wearing watches so this is more like using a phone. It comes with a little wireless charging cradle that sits on my nightstand right next to my cell charger. When I go to bed I take it off and put it on the cradle.

Otherwise, it just lasts me all day with no issues and has been a very neat bit of gadgetry. Nothing life-altering by any means but I got it on sale for $175 and found that to be acceptable for a watch that allows me to view notifications at a glance or occasionally toss off a voice command while driving. Even little things like mirroring turn-by-turn navigation directions are great when on a bike or motorcycle and you don't want to pull out your phone or mount it on the handlebars.

And the biggest (and possibly guiltiest) pleasure: I can make the face look like whatever I want. Loads of great designs out there for apps like Watchmaker and Facer allow you to download free faces from the creative community or make your own with some quick presets or some more ambitious Photoshop. I'm hoping Apple eventually adds this in later software revisions the way iOS eventually allowed you to change your wallpaper and ringtones.

I think the whole smart watch thing will be a minor hit for a while as the various models offer some level of gadgetry, a bit of gimmick, and a decent amount of usefulness at anywhere from $150 to $500+ depending on the maker. And in a way, I think that the non-essential nature of them makes the battery thing less of a problem. You charge it overnight (and in the case of my watch, you can recharge from empty in an hour or two if you plan on staying out late) and in the odd event that you forget your cradle while out of town, you still have your phone for all of the really useful and important stuff.

</comment></comment></comment><comment><USER9> There's a definite fear this time around to pan the Apple watch given how so many such predictions have been proven wrong in the past.

But reading between the lines , you can sense that many reviewers feel that it's a dud.

<comment><USER10> Now that it's in stores to try out (they have units on the table you can use the UI on in addition to the try on appointments) people should just go check it out for themselves.

I got the same sense from reading reviews, most seemed negative on it, like it was unfinished and not ready for primetime (wait till version 2 or 3 most would say).

I can tell you after going into the store and trying it out I left thinking it was a great product. The fit and finish is top notch and the UI is smooth and responsive. I couldn't test watch kit apps out so that might be an issue, but that'll be resolved once Apple releases a separate SDK for running on the watch which they said they would do later this year.

I'd say if you were previously worried by the reviews go check it out in person and you might be surprised.</comment></comment>


Mousemacs – A mouse-driven Emacs - <AUTHOR> https://github.com/corvideon/mousemacs <comment><USER2> Nice, but this doesn't go far enough imo. I love emacs but keep using Sublime on a daily basis because it has real, native[0] mouse handling and UI. My dream editor would be a Sublime UI on top of embedded emacs. That means:

\- Native mouse selection of text, proper copy/paste, ideally with a "narrow caret" instead of block cursor everywhere

\- Native graphical file tree with drag and drop

\- Native tabs with pretty drag and drop

\- Pixel-fine resizing of panes

\- Pixel-fine scrolling!!

[0]: Everywhere I say "native" above, I don't really care if it's GTK or electron (provided it's snappy) or whatever. I mean the nebulous feeling of having text areas work like every other text area on my desktop.

VimR ([https://github.com/qvacua/vimr](https://github.com/qvacua/vimr)) on mac was the closest to this I ever got, and I love that editor, but I'm not on macOS anymore.

edit: Oh g-----, I'm literally describing aquamacs. I wonder if anyone has tried to run it on linux with GNUstep or something ;__;

<comment><USER3> > Pixel-fine scrolling!!

I don't see why software not having this is apparently acceptable. It's just disorienting to have line jumps. That's not how the real world works.

Modern Linux software is pretty good at it (GTK, Qt) as is much Windows software. However the only git GUI I otherwise enjoy using that has it is Sublime Merge.

<comment><USER4> Beyond 'pretty', how does this help the user in any way?

I'm an emacs user and love it but lack of fine scrolling is hardly it's worst feature.

<comment><USER3> It's less disorienting. Humans are not built to track things that are at one place at one point in time and instantly another at the next moment.

I guess it feels fitting when you use a mouse wheel that has jumps in it anyway, but on a touchpad it feels highly unnatural.

</comment></comment></comment></comment><comment><USER5> Kinda strange.

Emacs is so inherently keyboard-focused that I fail to see the point of this... nor the need for it?!

<comment><USER6> I use Emacs as my primary... everything. But I totally see the point and need for mouse-driven functionality. Emacs only works if you have two functioning arms with hands on them. Put a coffee, a sandwich, a cat, a kid, a beer... in one of your hands, and Emacs is unusable. If my cat wants some attention, I can't keep typin' stuff.

Though, not sure why the mouse-driven features are also wrapped up making shortcuts match VS-Code etc. That makes it a lot less useful.

<comment><USER5> If you can't type, I'm not sure the mouse is going to get you much ahead either ;-)

But it's true that there might be a certain class of users with impediments for which a different input modality setup could be very beneficial. However, note that standard Emacs already provides menus and mouse support, it's just not what is commonly the focus of the editor.

</comment></comment></comment><comment><USER7> Mac has "Aquamcs" which is mac native emacs with a wierd blending of MacOS key commands and emacs commands.

It works better than expected. Its not perfect but maintains the recording/playback of macros I use all the time. The fact that mac shortcuts use "Command" which emacs doesn't use natively helps.

[https://aquamacs.org/about.html](https://aquamacs.org/about.html)

Look forward to trying mousemacs out.

-A

<comment><USER8> The official Emacs.app also supports using the Command shortcuts while keeping all the normal emacs commands the same. In general I find that the app plays nicely with MacOS and I prefer it over aquamacs since emacs.app is newer (right now version 27 vs 25.) And I think looks nicer once I've removed the menu bars.

<comment><USER9> except for cmd-c (apple copy) and cmd-w (emacs copy)

but mostly macos works well with emacs because... macos uses the basic emacs navigation and editing keys in all its text widgets.

control-a/e beginning/end of line

control-p/n previous/next line

control-k/y kill to end of line, yank

...

</comment></comment></comment><comment><USER10> Based on the title I hoped this was going to be emacs with acme-style mouse chording.

[1]: [http://acme.cat-v.org/](http://acme.cat-v.org/)

<comment><USER11> I was about to say the same thing! I suggest the author of this digs into acme (easy to run plan9 on a rpi!) and borrows some of the chording, because I'm not crazy about the menu driven mouse commands shown in the repo examples.

An "acmemacs" would be amazing - might be the only thing that could tear me from emacs at this point.

</comment></comment><comment><USER12> I think this is solving several different problems:

1) I would love to have a better way to manage tabs and multiple files in emacs. This piece seems awesome!

2) Good context menus aren't as important, but a definite win! emacs is useless here. But I'm not sure your context menus are the ones I want.

3) As someone who's used emacs for a long time, I would hate to have my emacs shortcuts replaced by standard ones. I don't want to remap my brain.

I wish there were a way to pick-and-choose.

<comment><USER13> > _3) As someone who 's used emacs for a long time, I would hate to have my > emacs shortcuts replaced by standard ones. I don't want to remap my brain._

As someone who's used Mac for a long time (and now Linux desktop, with similar shortcuts, plus spending most of my time in a browser like Chromium or Firefox), I chose other editors like Sublime and now VS Code partly because they use shortcuts that feel normal on those platforms so I didn't have to remap my brain. (More like my thumbs I think.) So to me the shortcuts changes in this project may be the most interesting part!

<comment><USER14> Don't talk about politics, religion or text editors at work, son.

They used to ban people for starting rWars on USENET (that is, outside of the forums specifically for rWars) back in the day.

<comment><USER12> I'm not sure anyone is actually fighting. We both like what we're used to, and neither of us is claiming it's better. We're both just agreeing we don't want to change.

People are allowed to like different things (except vi, obviously -- I hope we can all agree to that).

As a footnote: I'm comfortable with mainstream keyboard shortcuts too, but not in emacs. Those things do specific things in emacs, and would be a mess. If you remap ctrl-k, I won't have a way to cut a line anymore! I need that.

<comment><USER13> Hear, hear. Celebrate diversity!

FWIW, VS Code uses Ctrl+Shift+K by default for Delete Line. I'm used to it enough that I sometimes try it in other apps, like Chromium text boxes …

</comment></comment></comment></comment></comment><comment><USER15> The config files for this are well commented and explained. Great for someone new to emacs. Which I suppose is exactly who Mousemacs is for.

</comment><comment><USER16> This is the first step only. I remember in 1995 Stallman wanted Emacs to be "like Microsoft Word" with varying fonts and other formatting shit with hidden Tex-coding. Do it.

<comment><USER17> I do not understand the want to stick with fixed-width fonts in this day and age. We do not use the editor to punch cards anymore, nor do we type text on a character-cell terminal or a typewriter. With the high-resolution displays, code we write should look more like one that is found in some nice programming books - complete with bold-faced reserved words, italicized comments, and even some mathematical typesetting. This could even (re)open the path to the Holy Grail of literate programming!

<comment><USER18> > I do not understand the want to stick with fixed-width fonts in this day and > age.

Usually it involves alignment issues. Some people neatly align array entries, etc, and variable width fonts makes this look ugly. Also, people often put ASCII diagrams, etc in the comments, which are screwed up by non-monospace fonts.

> This could even (re)open the path to the Holy Grail of literate programming!

The Leo Editor[1] is your friend. It's the only such editor that seems to do it well. And by well, I mean "poor experience, but better than all the others."

[1] [https://leoeditor.com/](https://leoeditor.com/)

<comment><USER17> > _diagrams_

It would seem that being able to simply insert an image (or some kind of a link to one - similar to what you can do in HTML) would serve the purpose much better).

<comment><USER18> It definitely does, and I can do this in Emacs with Org Mode. However, I cannot convince the world to use Emacs and Org Mode. I appreciate Noah's frustration.

</comment></comment></comment></comment></comment><comment><USER19> This seems like a nice extension to Emacs for folks that want to use it but are stymied by the steep learning curve.

Personally I think the learning curve is worth it... especially with an aid like Spacemacs. It gives you the context and quick access without requiring a mouse and thus results in faster and more efficient interaction in the long run.

[https://github.com/syl20bnr/spacemacs](https://github.com/syl20bnr/spacemacs)

<comment><USER20> I believe that all available evidence suggests that keyboard-only editing is not actually faster or more efficient (I say this as a keyboard-only Emacs user).

<comment><USER21> Any links?

For me it seems like (haven't measured) being only on the keyboard or only on the mouse is faster than trying to switch between the two, if only because I avoid the mental context switching.

<comment><USER20> I just googled and it looks like my statement is true, with the caveat that "all the available evidence" is pretty much garbage.

I get terrible wrist pain when I even look at a mouse so editing speed is a secondary concern for me.

</comment></comment></comment></comment><comment><USER22> Very cool! I don't understand the extent to which this changes Emacs under the hood, though.

Do you think it'll still be able to run org-mode?

EDIT: Org-mode is working for me. I still don't know how to use it, but it's nice to be able to navigate through it via the right-click menus.

</comment><comment><USER23> I see a potential future use case for this when human-computer interaction will be done through brain interface. Will prolly be easier to integrate with nervous signals from brain to one hand (mouse interaction) compared to two hands (keyboard interaction).

</comment><comment> globular-toast One of the things that drew me to emacs initially was that I could customise it to reduce or, in most cases, eliminate mouse usage. Toolbars, scroll bars etc. were the first things to go. Just taking those away makes emacs must more attractive for me.

</comment><comment><USER24> Can we add clippy, too?

<comment><USER25> there you go: [https://github.com/Fuco1/clippy.el](https://github.com/Fuco1/clippy.el)

<comment><AUTHOR> I am almost tempted to add this.

</comment></comment></comment><comment><USER26> Would love a more GUI focused Emacs but don't change keyboard shortcuts I've built into my muscle memory please.

</comment><comment><USER27> Has someone tried this together with spacemacs?

</comment><comment><USER28> Thanks. I hate it.

</comment><comment><USER29> Mouse-driven Emacs is like a feet-driven car. Fred would have loved to see this.</comment>


Up To 30 Gbps: New Chip Enables Record-Breaking Wireless Data Transmission Speed - <AUTHOR> http://techcrunch.com/2011/11/22/up-to-30-gbps-new-chip-enables-record-breaking-wireless-data-transmission-speed/

<comment><USER2> This looks really interesting, but I'd love to hear from someone knowledgable in the physics of terahertz radio waves. There are often trade-offs involved with the frequency you choose. For example, 2.4 GHz just happens to penetrate common building materials (reasonably) well. The 5 GHz spectrum for 802.11n doesn't work as well in many cases.

</comment><comment><USER3> It's the good news, but the actual working chip is 1.5 Gbps, and 30 Gbps are planned for the future.

<comment><USER4> ... and production is 3-4 years out. So cost, speed and availability predictions need to be taken with a large grain of salt.</comment></comment>


Is Google losing it? - <AUTHOR>

Like Fred Wilson said, Google is no longer innovative, the last innovative product that came out of google which was home grown was Gmail in 2004, since then others have been startup's they acquired. The newest evidence to that hypothesis is boutiques.com <comment><USER2> Losing?</comment>


YC's Safe annotated by lawyers, founders, and investors on Casetext - <AUTHOR> https://casetext.com/contract/simple-agreement-for-future-equity <comment><USER2> I like it, but it would be more useful to skim the annotations if you displayed a title, or perhaps the first few words of the body text rather than the name of the annotator.

<comment><AUTHOR> This is absolutely something we can do. We'll try this out later today and see how it looks.

</comment></comment><comment><AUTHOR> I'm the CEO of Casetext -- we'd also like to use this opportunity to get feedback on our new annotations interface.

<comment><USER3> I hate the way the annotations move around on the right. Mousing over a paragraph makes the current label disappear, and a new label with some extra info slides in from the top of the page. It's incredibly distracting.

<comment><AUTHOR> Thanks for the feedback -- this is definitely something we can fix quickly.

<comment><USER4> I suggest actions don't up and down but instead just quickly fade in/out next to each para as you mouse over. Would be better to make them more subtle to make them less distracting, then you could reveal the whole thing when user hovers the right side.

I'd look at medium (their "add comment" and "add photo" ctas) - they are clear and not distracting.

Another thing that distracted me other than the animation was how "add tag" got in the way of the annotation link. I'd aim my mouse at the annotation link and the link would move before I click on it. It should stay put.

Would also be great being able to close annotations by clicking outside.

<comment><AUTHOR> Thanks for these thoughts. Just pushed some changes that may fix things (i.e., the "Add Tag" button doesn't appear about the person's name anymore). They don't fade in/out yet, although that's something we can do.

You can actually close the annotations by clicking on the text. We'll be making it possible to close based on clicking anywhere outside or by hitting escape soon.

</comment></comment></comment></comment></comment><comment><USER5> There appears to be a bug in Safari 7.0 that's causing every annotation to have doubled text. Thus a comment like this:

"Pro Rata Rights mean that the investor will be able to maintain his or her percentage in subsequent financing rounds by investing additional capital."

Actually appears in the DOM as:

"Pro Rata Rights mean that the investor will be able to maintain his or her percentage in subsequent financing rounds by investing additional capital.Pro Rata Rights mean that the investor will be able to maintain his or her percentage in subsequent financing rounds by investing additional capital."

Note the repeat, without any spacing, following the first .

Even more oddly, this pattern seems to occur for each paragraph of the original, so:

" Paragraph 1 blah blah blah. Blah blah blah blah.

Paragraph 2 blah blah blah. Wat. " shows up as: " Paragraph 1 blah blah blah. Blah blah blah blah.Paragraph 1 blah blah blah. Blah blah blah blah.

Paragraph 2 blah blah blah. Wat.Paragraph 2 blah blah blah. Wat. "

<comment><AUTHOR> Thanks for the heads up. For what it's worth, it appears that it was a problem with the version of AngularJS we were using (1.2.3). When we next push updates to the site and upgrade Angular, this problem should be fixed.

</comment></comment><comment><USER6> I would highlight the relevant paragraph when you expand an annotation. That's very solid. (Sticking with angular?)

</comment><comment><USER7> Jacob,

You should consider posting the "Safe Primer" for annotation too. Also, it may be helpful to add a notation stating which version of the Safe is being annotated (i.e., "Safe: Cap, no Discount").

</comment><comment><USER8> So YCVC notes/SAFE are capped now? I thought they were uncapped? IIRC they were in the Start Fund days.

<comment><AUTHOR> I'm not sure about the YCVC notes in particular, but if I had to guess, they are probably uncapped with a so-called "Most Favored Nation" clause that gives the YCVC safe-holders the benefit of the founders' most favorable (to the investor) terms.

The example of the safe we posted is specifically one with a valuation cap and no discount. But there are different options available, all available on YC's site: [http://ycombinator.com/safe/](http://ycombinator.com/safe/)

</comment></comment><comment><AUTHOR> One second everyone, someone's DOSing us... we'll be up again shortly.

</comment><comment><USER9> The ui of this is totally broken on mobile safari.

<comment><AUTHOR> Yikes. Would you mind sending a screenshot of what you're seeing to jake (at) casetext.com?</comment></comment>


Journal stem cell work 'blocked' - <AUTHOR> http://news.bbc.co.uk/1/hi/sci/tech/8490291.stm <comment><USER2> Surprise! Another "hot" field where accusations of gaming the peer review system are being made.</comment>


George Lucas Just Made $4 Billion Without Any VC Money - <AUTHOR> http://finance.yahoo.com/blogs/daily-ticker/george-lucas-just-made-4-billion-without-vc-213535737.html

<comment><USER2> Oh please,

The movie industry may not call them VC's but George Lucas didn't make Star Wars out of his own pocket money. It took a crap ton of investment money for him to become successful.

</comment><comment><USER3> Article doesn't mention the obvious one either - he didn't do with an exit strategy in mind, or necessarily to make a pile of cash, just to do what he loved.

</comment><comment><USER4> He kind of was leading technological development for a whole industry, too. Well deserved.

</comment><comment><USER5> This is one of those articles that deserves a middlebrow dismissal. =/</comment>


Rice Paddies And Math Tests - <AUTHOR> http://www.gladwell.com/outliers/outliers_excerpt3.html

<comment><USER3> I'd be interested to see some data on how children learning math in Hindi do, because the numbers are even less regular, enough so that even though there's a pattern, you still have to learn all the numbers from 1-100 individually. There are also more specific words for different fractions, such as a word for 3/4 that sounds nothing like the word for 1/4.

<http://www.sf.airnet.ne.jp/~ts/language/number/hindi.html>

[http://faculty.maxwell.syr.edu/jishnu/101/numbersfractions/d...](http://faculty.maxwell.syr.edu/jishnu/101/numbersfractions/default.asp)

(My apologies if any of this is wrong. I'm not a native speaker, just took a few years of Hindi in college.)

<comment><USER4> most schools in urban india and a large number of the rest are 'english- medium'.. which means i learnt math in math class (in english) and learnt to count in hindi in hindi class.. but never had to solve a math problem in hindi

i am currently learning japanese and can agree about the numbers being syllablically small.. but this language has it own complexities - <http://en.wikipedia.org/wiki/Japanese_counters> which require a speaker to think a lot as well

<comment><USER5> I agree with the comment above. But there is a large rural population in India that 'thinks numbers' in the native language.

May be the article is true only for numbers in the CJK (Chinese-Japense- Korean) languages.

Atleast in the 3 Indian languages I know, numbers are bad in all of them - <USER2> bad as it is in English.

<comment><USER6> Turkish is good in this respect. They even have have regular numbers from 11 to 19.

<comment><USER7> Yes, but the decades are not related to digits. Two is "iki" while twenty is "yirmi".

<comment><USER6> Yes. At least it's the relation is not visible to outsiders. Perhaps there's a hidden relation?

</comment></comment></comment></comment></comment></comment><comment><USER8> Interesting article overall, but I found the following a little spurious:

>For fractions, we say three fifths. The Chinese is literally, 'out of five parts, take three.' That's telling you conceptually what a fraction is. It's differentiating the denominator and the numerator.

It's not obvious to me that one is better than the other, and he's not providing data to support such a claim. Is it just me, or is he just playing with semantics here?

<comment><USER9> Miller, K. F., Smith, C. M., Zhu, J. & Zhang, H. Preschool origins of cross- national differences in mathematical competence: The role of number-naming systems. Psychological Science, 6, 56-60.

<comment><USER8> I just read this paper (it took me a while to get it) and it does not make any reference to fractions _at all_. It only supports the first claim:

>That difference means that Asian children learn to count much faster. Four year old Chinese children can count, on average, up to forty. American children...

It does not support the second claim:

>The regularity of their number systems also means that Asian children can perform basic functions—like addition—far more easily...

I don't have a copy of the book to hand (in India and haven't managed to find it yet) - I can only see the online excerpt. Does he cite other papers in support of the fractions claim and/or the second claim quoted above?

<comment><USER9> He only cites secondary sources in the book. I just linked to that paper because I happened to know about it offhand. (Wrote a couple papers about it in college.)

If you want to find the paper supporting the second claim, Gladwell explicitly uses the keyword number-naming systems so that is a pretty big clue. There can only be so many cognitive development papers with that as the independent variable, so it should be pretty easy to find. It wouldn't surprise me if the research supporting the second claim was done by the same researchers who did the other paper I linked to.

<comment><USER8> Thanks Alex. I guess I'll wait until I can get my hands on the book to find out what sources he is citing.

</comment></comment></comment></comment></comment><comment><USER10> Sounds fishy to me. In german, numbers are logical but excruciatingly long to say in words. There's no huge lag in german math skills because it takes a little longer to say the numbers than in english.

<comment><USER11> 123

Eins zwei drei

Hundert drei und zvanzig

Logical? (hope I didn't make a mistake there...)

<comment><USER12> Looks right. IIRC (studied German in college), numbers are read similarly to English, with the exception that the tens place is read last. Transliterated, you would get something like "three thousand, four hundred, seven and ninety" for 3,497.

</comment></comment></comment><comment><USER13> According to this logic, shouldn't kids from Kansas or Iowa do way better in math?

I'm Chinese myself, and I think there might be a simpler reason. Our schools public schools are way tougher. I'm talking 7 am to 5 pm, non stop learning hard. We're talking about doing trig in the sixth grade and calculus in middle school.

Those are the kinds of schools our parents went to and those are the kinds of schools they send their kids to. Instead of soccer practice or baseball games we take more math classes.

Also explains why we tend to suck at sports.

From my experience the difference in ability stems more from culture than from genetics.

<comment><USER14> > From my experience the difference in ability stems more from culture than > from genetics.

This is actually his point: the chapter from which this excerpt is taken is from the second half of the book, which is all about how our behavior (and thus our performance) is profoundly influenced by our cultural heritage. There's a great chapter, for instance, on how cultural differences regarding deference to authority resulted in Korean Air's high crash rate in the 90's.

There's no mention of the rice paddies in this excerpt, but Gladwell argues that rice paddy cultivation was considerably more complex and required considerably more labor than typical farming practices in the West, a long history of which resulted in a culture of persistence. (Which might explain just why Asian public schools are way tougher.)

<comment><USER13> Guess I should have read the OP - you caught me - tl;dr

</comment></comment></comment><comment><USER15> Ah yes, another hack who believes math is all about memorization and fast arithmetic. Who cares if our 7 year olds can add slower? We all add the same speed once we lift the calculator ban. And once you start doing real (abstract) math, this memorization advantage becomes completely useless. I'll believe the "Chinese Math Dominance" story when I see it.

<comment><USER16> You're not reading the hypothesis correctly:

 _Asian children, by contrast, don't face nearly that same sense of bafflement... maybe that makes them a little more likely to enjoy math, and maybe because they enjoy math a little more they try a little harder and take more math classes and are more willing to do their homework, and on and on, in a kind of virtuous circle._

The argument is not that the clarity of the Chinese-language numbers is, in itself, that big of an advantage once kids grow beyond four, five, or seven years of age. The argument is that kids who are comfortable with math at age four are more likely to remain happy with math throughout the rest of their schooling, whereas loss of confidence at an early age results in loss of future confidence.

Obviously, while you can test the difference in math skills among seven-year- olds, this stronger hypothesis is hard to test rigorously, because you can't easily control for all the other cultural differences. But it's a very interesting idea, nonetheless. One of the most amusing things about this hypothesis is that it mirrors the difference between the English and Chinese written languages: Chinese writing is badly designed compared to alphabetic systems, to the point where there are serious effects on the literacy rate. See Moser at <http://www.pinyin.info/readings/texts/moser.html> and DeFrancis' _The Chinese Language: Fact and Fantasy_ , linked from <http://www.pinyin.info/readings/chinese_language.html>

<comment><USER17> Pinyin.info is largely devoted to an anti-character crusade that doesn't represent mainstream academic thought. Mark, if you're reading this, I don't mean any disrespect to the work you've put into making the resource it is. I've sent many people there for the rules on pinyin punctuation and spacing.

DeFrancis was the undisputed pre-eminent sinologist of his time, however many of the literacy claims are unfounded. The truth of it is, China is a huge country, full of people speaking dozens of different languages and the Chinese writing system has helped its cohesion.

As a 6-year resident of Taiwan, I feel I have some capacity to comment on this. Here we use traditional characters, which are more complex than those currently in use in China, and despite not being as economically developed as the US, Taiwan has a _higher_ literacy rate. Japan does, too. For that matter, China's literacy rate is higher than other countries with similar levels of economic development, such as Brazil.

Using characters entails some disadvantages, but also allows for some benefits, such as increased reading speed and clearer differentiation of homonyms.

FYI Moser has long since conquered his difficulties and become a literate Chinese reader.

<comment><USER18> Taiwan is also mostly urban, whereas the literacy rate in China is reduced by those from rural, far flung provinces.

<comment><USER17> That's why comparing China with developed countries and blaming any literacy shortcomings on orthography just isn't fair.

<comment><USER18> Point taken.

</comment></comment></comment></comment></comment></comment><comment><USER19> This is why we need to teach numbers and concepts, not names.

I admit that the English number system is flawed, but that's what digits are for, right? 37 = 3(10s)7. Its just a shortcut, we can express 37 to be 3*10 + 7, but its just not worth saying every time

<comment><AUTHOR> You still have to say "thirty seven", or mentally say "three times ten plus seven", before you do the calculation.

<comment><USER20> I think his point, however, was that even an exclusive English speaker can communicate (in writing) arithmetic calculations without involving English. You don't have to 'mentally say' anything in English, so the inefficiency is mitigated.

</comment></comment></comment><comment><USER21> I thought he had a good point, but then I realized his intro test was rigged: twice he said "say them out loud", so I tried to memorize the sound of the numbers.

But then I thought about how I remember passwords, PINs, and phone numbers, and I don't memorize any of these by the sound of their digits (perhaps because it would be so inefficient in English!).

I remember sequences of digits (or chars) by visualizing how I use them, i.e., spatially. In this case, I pretended the 7 digits made up a phone number and mentally placed them on a phone. Now I can't seem to forget 485-3976.

</comment><comment><USER22> I disagree with the proof here. He implies that the two statements: Asian children have a simpler number system vocabulary. \- and - Asian children learn to count at a younger age.

prove the third:

A simpler number system vocabulary allows children to count at a younger age.

This may be true, but he implies it as fact, without even granting that they may be other factors at work. Like a better education system perhaps.

</comment><comment><USER23> Very interesting. I've never heard any breakdown of their being a different approach to numbers in any system so that was neat.

</comment><comment><USER24> If you passed, post here; I've been doing math all night so I kinda cheated. ;)

<comment><USER25> If you think 4 8 5 3 9 7 6 (Which I think was the string) is hard to remember at a glance, Try:

      FDC2:D343:5602:32:213:50FF:FE01:3842

I'd love to know what the cognitive impact of IPv6 has been on our ability to remember long strings of numbers.</comment></comment>


Google Makes Most of Close Ties to White House - <AUTHOR> http://www.wsj.com/articles/google-makes-most-of-close-ties-to-white-house-1427242076 <comment> Pat-rights All Google's done are undoubtedly corruption activities, Google wouldn't do all these just for an opportunities of being heard. We have concrete evidences that it corrupted a California Court, [http://www.pat- rights.com/Tse%20v%20Google.html](http://www.pat- rights.com/Tse%20v%20Google.html), and will never able to provide its side of story.</comment>


WorkerDOM from AMP: The DOM API in Web Workers - <AUTHOR> https://github.com/ampproject/worker-dom <comment><USER2> There are already implementations of DOM which can run in Web Workers: jsdom, xmldom, domino, via.js. How is WorkerDOM superior?</comment>


Ask HN: What are some unique skills startups look for - <AUTHOR>

To startup founders, what are some of the most valuable skills you feel are lacking in your current startup?<p>Eg. SEO expertise, twitter marketing, etc <comment><USER2> "SEO Expertise" is somewhat akin to saying "black magic voodoo".

</comment><comment><USER3> SEO expertise and Network</comment>


Ask HN: Why are there no programming books on Brainfuck? - <AUTHOR>

Or am I missing the point?<p>Is it meant to be just a hilariously difficult and esoteric language to learn? Just to say you know it? <comment><USER2> Brainfuck is just a set of symbols that map to the actions a Turing machine can make. I believe that the symbols themselves were chosen to make it difficult to read and write much like Whitespace. As for Turing machines, I'm sure there are programming books about them but I'm pretty sure their point is about studying computational theory rather than practical use.

</comment><comment><USER3> Yes, it's just an esoteric language intentionally meant to be difficult.</comment>


What to expect in NetBSD 7 - <AUTHOR> http://netbsd-news.me/NetBSD7/ <comment><USER2> The article is a few weeks old now. One change since it was written -- Raspberry Pi 2 SMP support has been added to -current and is expected to be part of the 7.0 release.

<comment><USER3> Hooray! I now have a use for my Pi2!

</comment></comment><comment><USER4> The accelerated graphics are heaven-sent (thanks @Riastradh). As much as having non-accelerated gfx was frustrating before, NetBSD was too charming to give up as my daily driver. Anybody who's curious to jump in should do it! Exciting times for a rock-steady well-thought-out OS...

<comment><USER5> Is there anything which might catch the eye of a regular linux user? (FreeBSD users would like to point out ZFS, jails etc., OpenBSD users usually point out pf/security and DragonFlyBSD users point out Hammer FS and an inviting community).

<comment><USER4> That's a thoughtful question.

Let me ramble...

1) I'd say the "fit and finish" is remarkable. But everybody probably likes what they've got with their OS, so maybe that's not worth much.

2) If you're into firewalling/networking, it does have the venerable ipf, OpenBSDs pf, and the shiny-new npf for packet filtering -- and the network stack that held the Internet "land speed" record. Twice[0]

3) there is remarkable kernel research that is going on, that research makes the kernel available to _YOU_ [1][2]

4) pkgsrc is topnotch. And others use it too, so like the famously portable OS, the 3rd party software is tested in the realworld on disparate machines.[3][4]

5) The community is small enough, friendly enough, and smart enough that it's simple to get into and has a high signal-to-noise ratio.[5]

6) Other interesting security[6], virtualization[7]

7) Good documentation, good code (forged by years of portability -- getting code running on so many different architectures doesn't happen by accident, and the lessons are carried on. And to be clear, unlike Linux, the NetBSD code that runs on (eg) a Vax is from the same codebase than runs on an 8-way amd64... versus (afaik) Linux where ea. target is pretty much a rewrite.)

8) I could go on... if you have more questions, don't hesitate, or better, drop in on #netbsd IRC channel on Freenode[8].

[0] [http://www.netbsd.org/gallery/research.html#internet2-landsp...](http://www.netbsd.org/gallery/research.html#internet2-landspeed)

[1] [http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD- current](http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current)

[2] [https://wiki.netbsd.org/rumpkernel/](https://wiki.netbsd.org/rumpkernel/)

[3] [http://pkgsrc.joyent.com/](http://pkgsrc.joyent.com/)

[4] [https://github.com/minix3/pkgsrc](https://github.com/minix3/pkgsrc)

[5] [https://www.netbsd.org/community/](https://www.netbsd.org/community/)

[6] [http://en.wikipedia.org/wiki/Veriexec](http://en.wikipedia.org/wiki/Veriexec)

[7] [http://en.wikipedia.org/wiki/NetBSD#Virtualization](http://en.wikipedia.org/wiki/NetBSD#Virtualization)

[8] irc.freenode.net

Edit: Match my parens, s/to/too/, link to freenode.

<comment><USER6> _And to be clear, unlike Linux, the NetBSD code that runs on (eg) a Vax is from the same codebase than runs on an 8-way amd64... versus (afaik) Linux where ea. target is pretty much a rewrite._

That is not really an accurate way to characterise how the different Linux target architectures are supported in the source. As you would expect, the vast majority of the code is in fact shared.

<comment><USER4> Agreed -- and people are proud (NetBSD) or defensive (Linux) of the characterization I made -- and while of _course_ every single line isn't re- written, and presumably Linux kernal devs will talk to ea. other, or perhaps one person maintains multiple architectures and therefore gets automatic code/idea sharing, NetBSD goes through pains to make sure all the supported platforms' origin is the one, single repository that is NetBSD.

<comment><USER6> That's really not how it is. For example, here the one single implementation of the madvise() syscall in Linux:

[http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/mm/madvise.c?id=v4.0#n458)

This entire file is compiled on all architectures with MMUs (madvise() is pointless on architectures without MMUs and hence without virtual memory). Everything architecture-specific in this file is abstracted away by macros like PAGE_SIZE and PAGE_SHIFT.

</comment></comment></comment></comment></comment></comment><comment><USER7> [http://netbsd-news.me/](http://netbsd-news.me/) seems to be misconfigured. It returns a page from [http://www.saveosx.org/](http://www.saveosx.org/).

<comment><USER8> fixed that, thanks for pointing it out

</comment></comment><comment><USER9> I didn't realize NetBSD was playing the catch up game with what other distros have had for some time, like ZFS. That's disappointing.

<comment><USER3> What's a "distro" have to do with BSD? The only BSD that has ZFS is FreeBSD.

<comment><USER9> Well it seems I don't use 'distro' properly. I guess it only concerns Linux, but I personally don't see any reason it can't be used for OS flavors in general. Hell, the website distrowatch includes BSD and everything in between. Is there a similar phrase for BSD variants?

And ZFS is on a lot more than just FreeBSD, even if it's not official. ZFS started on OpenSolaris, not on FreeBSD. OS X has a port. Then FreeBSD got it's port. Linux has a stable port. And there are NAS OS's shipping with it like FreeNAS, TrueNAS, and a device called ReadyDATA by Netgear that has it.

I was mostly surprised at this: "The good stuff that probably won't make it to NetBSD 7: Stable ZFS." So you're telling me ZFS isn't considered stable on NetBSD? It seems to be that it's pretty stable on quite a few other platforms, some mentioned above.

<comment><USER3> Linux distros share a kernel -- the Linux kernel. Maybe different versions, maybe a few different patches here and there -- but unquestionably the same kernel.

In BSD world they're completely separate OSes. Their kernels have evolved differently. They may have similar ancestry. You can't just copy and paste code from one to another and expect it to work.</comment></comment></comment></comment>


How to Contribute to Open Source - <AUTHOR> https://opensource.guide/how-to-contribute/ <comment><USER2> Nice guide. Here is an older and simpler one from SmartBear: [https://smartbear.com/blog/test-and-monitor/14-ways-to- contr...](https://smartbear.com/blog/test-and-monitor/14-ways-to-contribute- to-open-source-without-being).</comment>


If you got hit by a Google Algo update... where do you go? - <AUTHOR>

One of my websites (a forum) that we do no black-hat stuff on got hit by one of the recent Google algo updates. I can't figure out why. It's a forum full of great information, a thriving community.
Can't think of a reason why Google would penalize it. I've done the resubmission form and Google responds back saying no MANUAL action has been taken on the site... so I can only assume all the traffic was pulled because of some algo issue.
I don't know who to contact, I'm at wits end. Anyone know what I can do?
For the record, the site in question is: nexustablets.net <comment><USER2> Well, you have more than 98% of your links with this anchor text: nexus tablets. Out of 118,824, about 118,100 use that anchor text. (I used ahrefs to get this)

That's a massive flag right there. Many of these are sitewide links (which, again, isn't going to help your case). The only saving grace is that many of these sites are pretty relevant to your site. Even then, it looks like it got hit by the Penguin update or the EMD update (since your domain's an exact match, and just about every link has that as the anchor text). There isn't a need for any manual action... there's a massive footprint as far as your backlinks profile are concerned.

Here's the good thing: It seems you have interlinked a number of your forums from their footer. That accounts for a majority of your links... and because it's in the footer, it's sitewide. Because you own those sites, you can perhaps remove the links.

The sites I have seen recover from Penguin have either removed the "bad" backlinks, or diluted their then backlink profile. In your case, it's a bit easier. If it's hit by the EMD update, I haven't seen any site recover from that yet so can't say anything.

</comment><comment><USER3> Have you used the google webmaster tools? Any clues there?

<comment><AUTHOR> Yes, and no clues whatsoever. We did turn off the Off-Topic section from being visible to guests, so that triggered a bunch of Soft 404 errors which I've now added to robots.txt -- we did this to try and clean up any perception of the site having low quality content. Though, honestly, I think the off-topic stuff should be fine anyway... we are kind of grasping at straws.</comment></comment>


Why Do So Many Women Who Study Engineering Leave the Field? - <AUTHOR> https://hbr.org/2016/08/why-do-so-many-women-who-study-engineering-leave-the-field <comment><AUTHOR> "Women make up 20% of engineering graduates, but it's been estimated that nearly 40% of women who earn engineering degrees either quit or never enter the profession...

When working with male classmates, for example, they often spoke of being relegated to doing routine managerial and secretarial jobs, and of being excluded from the "real" engineering work...

This second round of gender stereotyping in the workplace, coupled with unchallenging projects, blatant sexual harassment, and greater isolation from supportive networks, leads many female students to revisit their ambitions. Women begin to question whether engineering is what they really want to do."

<comment><AUTHOR> Evidence that diversity on a team means better ideas and outcomes: [http://www.scientificamerican.com/article/how-diversity- make...](http://www.scientificamerican.com/article/how-diversity-makes-us- smarter/)

</comment></comment><comment><USER2> I strongly recommend that people think about workplace diversity when considering job offers. Explicitly ask about during recruitment phases and think seriously about passing on roles where the teams are dominated by young white males.

I'm currently in a dev team 60:40 females:males and with a good mix of skills/ages/cultures and it's really great.</comment>


I found my 17yo backup but can't find the PSU. Please help me find one - <AUTHOR> http://imgur.com/a/f7fWg <comment><USER2> [http://knowledge.seagate.com/articles/en_US/FAQ/186849en](http://knowledge.seagate.com/articles/en_US/FAQ/186849en)

Links to images of the power supply labels which tell you the power supply is 12v with - on the outside.

You can just use a universal adapter for that.

</comment><comment><USER3> [https://smile.amazon.com/Adapter-Maxtor-OneTouch-Personal- St...](https://smile.amazon.com/Adapter-Maxtor-OneTouch-Personal- Storage/dp/B002RURFGS?sa-no-redirect=1)

</comment><comment><USER4> 12v 3 amp, center +, direct current, as written on the label

</comment><comment><USER5> Crack it open and use it as a normal drive.</comment>


As legacy media cuts back on FOIA, digital-only news outlets step in - <AUTHOR> http://www.cjr.org/first_person/foia_requests_down_legacy.php <comment><USER2> Leading the way is, surprisingly, Buzzfeed. They plan on doing A/B testing on their FOIA requests, and releasing their own report calling out offending agencies. This will be welcome information.</comment>


Cracking the Crypto War - <AUTHOR> https://www.wired.com/story/crypto-war-clear-encryption/ <comment><USER2> Some insightful comments from Matthew Green on Twitter.

[https://twitter.com/matthew_d_green/status/98922218828795494...](https://twitter.com/matthew_d_green/status/989222188287954945)</comment>


There are 2,373 squirrels in Central Park. I know because I helped count them - <AUTHOR> https://www.nytimes.com/interactive/2020/01/08/nyregion/central-park-squirrel-census.html <comment><USER2> Central Park has 843 acres. That means there are an average of 2.8 squirrels/acre. That seems low. I think they probably missed a lot of squirrels.</comment>