Presumption of stupidity - <AUTHOR> http://www.aaronkharris.com/presumption-of-stupitidy <comment><USER2> Chesterton's Fence:

> In the matter of reforming things, as distinct from deforming them, there is > one plain and simple principle; a principle which will probably be called a > paradox. There exists in such a case a certain institution or law; let us > say, for the sake of simplicity, a fence or gate erected across a road. The > more modern type of reformer goes gaily up to it and says, "I don't see the > use of this; let us clear it away." To which the more intelligent type of > reformer will do well to answer: "If you don't see the use of it, I > certainly won't let you clear it away. Go away and think. Then, when you can > come back and tell me that you do see the use of it, I may allow you to > destroy it.

<comment><USER3> This philosophy is one of the cornerstones of my engineering practice. IFF you can describe why something is there - without using shortcuts/crutches like 'their dumb' \- then we may be able to consider changing it. Otherwise, it's dangerous and risky to fool with it. Too many times did I see something absurd and paint myself into a corner trying to 'fix' it, when there really _was_ a bizarre edge case that this covered. (And in plants, you usually only find these edge cases after enormously expensive production loss events!)

And it's a fantastic principle in general, since it's like the technical equivalent of the Principle of Charity.

( [http://philosophy.lander.edu/oriental/charity.html](http://philosophy.lander.edu/oriental/charity.html) )

<comment><USER4> Chesterton's Fence should be one of the core principles of software development, and it calls to mind the famous "Never rewrite software" article.

If you're refactoring, you can use unit tests and proofs of equivalence to demonstrate that your changes don't pose a threat. If you're rewriting a whole codebase, you're likely to wander down the same paths of "wait, the simple way doesn't work" that the person before you took.

Even bafflingly small changes like removing always-false tests have been known to break code, which ought to inspire real hesitation any time you see "stupid" code written by a smart person.

<comment> loup-vaillant > _Even bafflingly small changes like removing always-false tests have been > known to break code_

Okay, how is this even _possible_? Reflection/pre-processing magic?

<comment><USER5> Compiler codegen bugs.

<comment><USER6> I've had a few compiler bugs where, adding an if false or changing the order of an if test 'fixes' things. And the complement changing the code exposes a compiler bug. And also, new improved compiler results in code that's broken.

Other issues I run into a fair amount is dealing with hardware/naked interrupts often involves a lot of subtle timing and read/write access issues. Sometimes this happens in code you don't own.

</comment></comment></comment></comment></comment></comment><comment><USER7> The same presumption happens for people, too. Developers tend to assume that the people that wrote the terribly messy code that you inherited were incompetent. I think a much more productive and healthy attitude is to assume that everyone was doing the best they could, given their resources, knowledge, and deadlines at the time.

That might be a false assumption (look, some people just don't care) but you gain very little by complaining and getting mad at things that already happened.

We love to complain about things our predecessors did wrong, but often, we don't do those things either :)

<comment><USER8> Some of the worst code I've had to work with in my nearly 10-year long career so far was written by one of the smartest programmer's I've met. His problem was that everything because an exercise in designing this all-encompassing abstracted-to-hell-and-back web of interfaces, services, aggregates, domains, etc etc.

Indicative of this was a request to take a table of data that already existed (on a website) and add a button to export a CSV of that data. For anyone familiar with .NET (and I assume most other languages) if you've already got the data in the format you want to export this is literally a 10-minute task, _including_ a unit test or two for the functionality. His quote was something on order of 18 hours which included time to write a set of TableDataExportService methods that would support a whole host of file formats in the future.

<comment><USER9> YAGNI.

Software should be implemented as simple as possible, and then refactored as necessary when new functionality is required (the only exception is things you are very sure is going to be needed, e.g a password reset functionality on a password dialog).

Anyhow that is my development philosophy.

<comment><USER8> Yeah this was some of the most anti-YAGNI stuff I've seen.

Which is not meant to detract from the fact that the code was great 99% of the time. It just took 10x longer than it should have and cost 10x as much and half of it was never used.

</comment></comment></comment></comment><comment><USER10> To generalize: competitors in a market usually behave rationally, and what looks like "stupid" behavior from afar may actually be unseen incentives.

Which suggests a test for your understanding of a market: can you map out the incentives and explain why what looks like apparently-irrational behavior is happening?

For example, in healthcare, we waste 30%+ of the $3T we spend each year. Much of that waste is due to hospital readmissions for an ongoing condition like heart failure. Startups sometimes try to fix this by developing a special machine learning algorithm to predict readmissions and apply an intervention. But even when the technology succeeds, the business fails: hospitals charge for readmissions, so there's an active disincentive for the hospital to buy the product. (That is now changing with ACOs, and a change in incentives is an opportunity for new companies.)

<comment><USER11> I don't understand your comment. You say "we waste 30%", but then say "hospitals charge". Who's the "we" who's wasting 30%, and why are startups trying to sell something to prevent X to the people who _make_ money from X, rather than to the people who _lose_ money from X?

<comment><USER10> "We" referred to US healthcare spending [1], and the party with the right incentive for this problem is the payers: Medicare, Medicaid, and private insurance like Aetna, Blue Shield, United Healthcare, etc.

While the payers have the incentive to reduce readmissions (saves them money, leading to lower insurance premiums for you), they don't usually have the access to do so -- they're not the one seeing the patient or prescribing medicine.

The payers could, of course, try to change the way that THEY reimburse the hospital to align the incentives. For Medicare and Medicaid, that requires a law--which is why the Affordable Care Act is creating opportunities for new startups as it rolls out. For private insurance, I think they'd like to change reimbursement, but they have relatively little market power compared to healthcare providers: [http://rockhealth.com/wp- content/uploads/2012/12/Kocher-et-a...](http://rockhealth.com/wp- content/uploads/2012/12/Kocher-et-al-Overcoming-the-Pricing-Power-of- Hospitals.pdf)

[1] Completely different set of incentives (and thus problems) in other healthcare systems.

<comment><USER11> That clarifies things, thank you.

</comment></comment></comment></comment><comment><USER12> I have never disparaged my competitors, but I'm a small fry. I can say that during four years at Microsoft (1996-2000, Development Tools group) I never heard the products of competitors disparaged that way. In fact, there was a weekly presentation of competing products and invariably the interest was in where we were lacking, not what was bad about them.

Likewise when customers came to visit us at trade shows my boss would sit politely through their compliments, then immediately jump to the question "So what don't you like about our product?"

Fast forward to today. I'm friends with top people at a Really Big Guitar Company and a Huge Amplifier company. Even in private, these C-level execs show nothing but respect for products of their competitors. They are not ashamed to own and even personally use said products (especially vintage ones).

It seems to me that dissing your competitors even privately can make you dangerously blind to the challenges they pose to you, set a bad example for your employees, and also restrict your job prospects should you decide to work for a competitor one day.

<comment><USER13> Interesting - thank you for sharing this.

</comment></comment><comment><USER14> This is a great thing to consider, and I think this presumption of stupidity bleeds over into other areas of life too.

Developers: inherited code is considered guilty until proven innocent. Or maybe more accurately, guilty until you've rewritten it. Surely the old developer had no idea what they were doing.

The "other faction": Democrats/Republicans, different religions, rich vs. poor people... most generalizations about the faction you don't belong to start off with thinking "they're so stupid". "Look at those Republicans/Democrats. Can't they see that Trump/Obama is just lying through his teeth?"

Bad actors: The presumption of stupidity carries over into the way people think about computer hackers and terrorists and the like. You'll see stories about how "those terrorists are learning how to use cell phones to detonate bombs!" or how "criminals are migrating online to prey on people with phishing attacks!" The underlying assumption is that they're stupid, but getting (dangerously) smarter.

I think we'd make a lot more headway in most areas by assuming our competitors, detractors, and wrong-doers are probably already pretty smart.

<comment><USER15> > Inherited code is considered guilty until proven innocent. Or maybe more > accurately, guilty until you've rewritten it.

I'm facing this dilemma right now, and I find it a whole lot more nuanced. The previous dev definitely had the right ideas, but he also produced XXXXX lines of code. I would take me years to wrap my head around the reasons for all these lines. Is this a bug or a feature? It would take me weeks to rewrite it, drop 75% of the corner cases for which I have no test case / clue why they have been coded. Then become the grumpy old dev that says "no" to 95% of feature requests and keep things simple. At the risk of my job.

<comment><USER7> You might find value in exploring the idea of Characterization Tests or Software Seams.

<comment><USER16> or Working Effectively with Legacy Software.

</comment></comment></comment></comment><comment><USER17> A lot of people seem to be unaware that companies survive by satisficing. That is, you don't have to do everything "right" to succeed in business. You just have to do most things well enough to not fail (don't break the law, don't forget to file your paperwork, pay your bills, etc.), and a few (one?) things outstandingly enough to win customers.

We've been brought up in school to think we have to get nearly every answer right on the test in order to get a good grade (and get more than half of the answers right just to not flunk out). In the real world, getting one right answer, and not screwing the rest up too badly is often enough (and sometimes only barely achievable!).

So maybe your competitor did something "stupid" because they're stupid, or maybe it's because that thing doesn't actually matter that much, and they're focused on doing something else incredibly well instead.

</comment><comment><USER18> An important line in the piece:

 _" Of course, just because you presume intelligence doesn't mean that every decision made was smart."_

I'd rephrase as follows: it's unwise to assume stupidity on the part of your competition, but it's very wise to allow the possibility of stupidity.

With the corollary that if there's an inexpensive way to capitalise on that stupidity if it exists, it's probably worth trying, just in case the thing that's walking like a duck and quacking like a duck is in fact a duck.

As a tangent to that - the chances that assumptions of stupidity are correct go up in direct proportion to your level of domain knowledge.

I see a lot of non-film people say "the movie industry does $FOO and that's really stupid", for example, and 95% of the time, they're wrong and there are good reasons for doing $FOO.

However, I also see people who know the film world (including me) say "a lot of / most filmmakers do $BAR and it's dumb" \- and $BAR has a considerably higher chance of actually being a dumb, common mistake.

<comment><USER19> A little more succinct might be: "It's unwise to assume stupidity on the part of your competition, but don't rule out stupidity."

</comment></comment><comment><USER20> I had the experience, that things people identify as "stupid decisions" are often just "economical decisions"

For example, a company I worked for had the best technology, but bad UI and the competitors had good UI, but their tech was old and inaccurate.

For years we thought they were imbeciles, because they didn't update their tech and we would smash them in the future, because they cannot catch up with us.

But in the end the customers bought the software with the better UI and didn't look behind the scenes.

So their decision was logical. Why pour money and time in parts of the software when noone wants to pay for this.

</comment><comment><USER21> This sounds like an instance of the fundamental attribution error [1]. It's a known human cognitive bias to blame others' failings on internal characteristics while seeing your own situation as more of a product of external influences.

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

<comment><USER22> Also relevant is the reversed phrase, "Never attribute to stupidity that which can be adequately explained by X (some other reasonable cause)."

</comment></comment><comment><USER23> The important thing in analyzing a competitor's behavior is to understand the incentives motivating that behavior.

A common example in startupland is a company whose senior management has short term incentives that reward a fast exit over long term growth. That company may very well behave in ways that appear dumb to competitors with a long term focus. But if the "seasoned" CEO and his cronies get their compensation even in a mediocre deal, why bother trying to build a company for the ages when they can cash out, rest a bit and land in a similar situation at the next gig?

</comment><comment><USER24> When I read the essay, I thought of P Thiel's question of self-reflection that analyzes in the reverse direction:

 _" What important truth do very few people agree with you on?"_[1]

I interpret " _truth_ " to really be a highly-opinionated belief rather than something like "2+2=4". In other words, what factors do you believe in that would make the business model successful that outsiders would dismiss as insane or stupid?

(On trivia related note: I notice the blog as the title of "stupitidy" instead of "stupidity" so I'm not sure if there's an inside joke I missed.)

[1][http://fortune.com/2014/09/04/peter-thiels-the-challenge- of-...](http://fortune.com/2014/09/04/peter-thiels-the-challenge-of-the- future/)

</comment><comment><USER25> Founders presume the stupidity of the competition because they're arrogant. Silicon valley, with it's notion of creative destruction and disrupting the establishment, encourages arrogance. We're blinded by the notion that new always trumps old, so we never consider that the established industry has reasons behind how it runs.

<comment><USER26> I agree, but I think this is what makes SV wonderful. You have to be somewhat naive to think your approach is going to be better than the status quo, particularly when your competition is well established, and probably well capitalized.

The reason why big companies can't turn on a dime is that they have a lot of people who work for them, and an existing customer base. It's difficult to align all of those people on a new, and potentially better way of solving a problem. It's not that they are collectively "idiots", it's that they have an established business with an established track record. This is quintessentially the Innovators Dilemma. Technology markets _almost always_ move downmarket to the cheaper solution which at first looks like a "toy".

<comment><USER25> Yes! I wish more people would actually read that book instead of throwing the word "disruption" around vaguely. After reading it, you'll realize the established business almost always has the advantage, and start ups only succeed in certain environments.

</comment></comment></comment><comment><USER27> One thing I learned the hard way is that if you are on the right track, your competitors are probably barking up the same tree and are further along than you would think baes on what is public.

For instance there was a period of many years where both Google and Bing image search were embarrassingly bad and I was able to build something far better for a certain range of queries.

It took me a year to build out my system but in that year, Bing and Google both improved dramatically, so my demo comparing results with them was no longer impressive at all.

<comment><USER28> Technology has some phase changes, where it suddenly changes from "doing X is extremely hard" to "hey, X is actually very easy to do!" without any ado, and no obvious reasons.

There are too many histories where after a long time of nothing happening, everybody suddenly starts working on the same problem, without any kind of coordination.

</comment></comment><comment><USER29> Great advice.

I do think that you should try to think about how you might try to solve something before looking at what your competitors do. The reason being that it's easy to trap our minds into thinking that there are no other solutions unless they fit into a similar box of what's already working. Naïveté combined with thinking for yourself can often be a powerful reason why many startups succeed.

If your solution ends up looking similar, at least, it was likely derived from first principals vs the path of least resistance: blind copying.

</comment><comment><USER30> I tend to err on the side of caution with stuff like this, for instance when inheriting a code-base I assume the previous author actually knew what he/she was doing. But _sometimes_ (not often) that can work against you as well. For instance when after spending sufficient time with said codebase you realize the original writer was entirely out of their depth and this was likely the first time they'd attempted to write something this complex.

But more often than not it is the presumption of intelligence that pays off.

</comment><comment><USER31> I couldn't disagree more. When Mark Zuckerberg turned down $1 billion from Yahoo[1] when he was 22, and FB was two years old at the time, because they were "stupid and didn't get it, so they obviously were't valuing the company" properly he was right.

The direct quote is:

>Thiel described the argument Zuckerberg finally came down on like this: "[Yahoo] had no definitive idea about the future. They did not properly value things that did not yet exist so they were therefore undervaluing the business."

Yahoo's market capitalization in July 2006 was $42.51 billion. A 22 year-old presumed they were stupid, and he was right. [2]

Today FB has a market cap of $264.91B and Yahoo? Down to $35 billion after 9 years of growth.

\--

[1] [http://www.inc.com/allison-fass/peter-thiel-mark- zuckerberg-...](http://www.inc.com/allison-fass/peter-thiel-mark-zuckerberg- luck-day-facebook-turned-down-billion-dollars.html)

[2] by the way to get the market valuation at the time, I did this search: [http://www.wolframalpha.com/input/?i=what+was+yahoo%27s+mark...](http://www.wolframalpha.com/input/?i=what+was+yahoo%27s+market+capitalization+in+july+2006) I can't believe it worked! I used wolframalpha because this is the kind of search they promise they can answer - and they were right, they actually delivered. Nobody else on the face of the planet does this, and it shouldn't even be possible. But it is. If you think something is possible, JUST DO IT. If you think your competitors are stupid (compared to what you think you can do), you're probably right. (or you wouldn't have that thought.)

<comment><USER32> > If you think your competitors are stupid (compared to what you think you can > do), you're probably right. (or you wouldn't have that thought.) No, you are > probably not the next Zuckerberg, or Jobs, or Page. If you don't understand > why your behaving a certain way its much more likely that you are the one > who doesn't understand the market.

<comment><USER31> yaur, I'll simply have to disagree with you. If you ask most people "why is Nike stupid, why are their running shoes completely wrong" nobody would give you an answer, nor do I have an answer. Anyone (including me) would say: "They're not stupid, they put billions of dollars of research into engineering and have a great understanding, their shoes are very comfortable and that's why they can charge $100+ for them."

... except for the 50 people in the world who know something that Nike doesn't. Those 50 people who _do_ have an answer to that question are the people who can topple them by doing something better.

Nobody delusional can explain something clearly, and answer all your questions about it - if someone clearly explains something and you think they're delusional for it, likely you're just not qualified to judge. You may be the kind of person who, if you got back sent 1,000 years into the past, would learn to ride a horse and learn some trade, because it's obvious that recreating anything from the future is "impossible", or someone would do it. Nothing wrong with that. Just doesn't apply to startups.

That advice in the context of startups is simply completely wrong, irrelevant, and inappropriate. Couldn't disagree with it more.

</comment></comment></comment><comment><USER33> I think this is the classic problem of advice giving that's so prevalent in the startup community today. It won't be too long until we're all praising a tweet or article that talks about only those who brashly challenge the status quo and assume the entrenched players are vulnerable, bogged down with legacy issues and fat and lazy on an existing revenue stream are ripe for the disrupting. Those who sit back and say "Well maybe there's a reason they do things this way I'm not sure" aren't bold enough and won't be the recipients of the spoils of disruption.

Not that this article is bad. It's just datapoint 107 that a founder has to reconcile with all the other competing advice.

<comment><USER34> Many times throughout the Entrepreneurial Thought Leaders podcast[1], a founder expresses the sentiment, "If I had known how hard it was going to be, I might not have started the company." The difficulty discounting has also been cited as the reason why many successful founders are young and inexperienced. So while hubris can lead to disastrous consequences for engineers, it could be viewed as an asset for inciting action.

[1] [http://ecorner.stanford.edu/podcasts.html](http://ecorner.stanford.edu/podcasts.html)

</comment></comment><comment> bro-stick Not much else to add. Presume a larger, smarter, better funded team is working stealthily in another office somewhere to kick our ass... anything else is complacency. Worse, following that path, leads to hubris at some juncture: excuses rationalizing cutting the wrong corners or shortchanging the customer that could prove fatal in a game of inches in the marketplace. There are at least a quadrillion ways to fail, and 99.997% of them will be my doing. Rational paranoia is healthy, because your product/service needs to be so well-regarded by people other than the team or supporters that it demoralizes potential adversaries that they don't want to compete. Even then, it still may not be currently as good in other key areas of focus as a competitors.

(Btw, the Thiel view of not picking fights you can't dominate and Buffett's sticking to defensible business models is a good mindset to calibrate a venture's success per risk gut perception. And with timing, team and execution you might just make something that hits.)

</comment><comment><USER35> Great article, taking the thinking further...

Everybody watches their competitors, it's entirely natural. It's solid advice to study them, and try to stay/get ahead of them where possible. This doesn't just apply to app features, but every facet of the business across many disciplines (sales/marketing/development/back office etc).

On the other hand, building a business based solely on a competitor's business decisions and not doing your own homework is the path to madness. We might take inspiration from our competitors, but we always check in with our customers next to make sure they actually want the feature. It's also our job to get feedback on not just what we're doing but also how we're planning to do it, as our users might have unique business requirements that our competitor's users do not.

</comment><comment> artumi-richard I think you can generalise one more step up. Markets that look horribly inefficient may well not be.

<comment><USER36> Or maybe they are ;) How to find out? For some people, the only way to confirm is to try and be tested.

</comment></comment><comment><USER37> People may have a sense of superiority, especially smart ones. Chess world champion (and genius) Bobby Fischer once said: "My opponents make good moves too. Sometimes I don't take these things into consideration".

</comment><comment><USER38> This mindset can be seen in other systems of thought. There are a large number of species known to man, yet we somehow think that we are the pinnacle of the tree of life, despite the fact that this is statistically highly unlikely when only taking into account pure numbers. Considering the dimensions now accessible to us that were completely unknown even 500 years ago, it doesn't seem a large leap at all to posit that there are other dimensions we are currentlt unaware of that contain life forms in the same tree as ours that are far more advanced and perhaps even invisible to us.

</comment><comment><USER39> Love the (deliberate? ironic?) mis-spelling of stupidity in the title/url.

<comment><USER40> Wish I could claim to have been either deliberate or ironic...but I actually got careless. Thanks for pointing it out!

</comment></comment><comment><USER41> This is so true. As a investor, I hear a lot of pitches where the founders say their competitive advantage is that they execute better (the flip side of believing everyone else is dumb is believing you're especially smart). Do you know who else claims they "execute better"? Everyone. That kind of attitude usually reveals that a founder doesn't have a real sense of what makes their company special and defensible, and is a bit of a yellow flag for investors -- well, at least for me.

</comment><comment><USER42> Working in academia, I've experienced this too. I've read work in my field of research that I dismissed as bad work or not worthwhile, simply because I didn't fully understand them. Too complicated, strange background assumptions, not well motivated, etcetera.

Then later, while developing my own work, I find that I end up with the same complications, that I'm forced to make the same background assumptions, and I have the same difficulty in motivating my choices.

</comment><comment><USER43> Uh, I was thinking this article is more business-side than operational? Easily put: a business exists if it stays afloat and fences are often the way not to go under, even if they appear stupid from outside. Many times, fences are the only common ground between sellers and buyers. Removing fences is, a lot of times, pretty stupid = you geniuses operate at a loss and survive from artificial money or VCs until you are allowed to.

</comment><comment><USER4> This is an excellent observation. When you encounter a suboptimal system, there's a substantial chance that it either produces some unnoticed benefit or results from some coordination problem that can't be overcome by "just not doing that".

In either case, successful solutions have to work around the gap in the system rather than simply charging into it.

</comment><comment><USER44> Despite the flaws in the rational model of economics and the efficient market hypothesis more generally, I have always been fond of the more humble, observant posture it gives us in considering others' behavior. The flaws in the rational model are well-known. But as a presumption, it certainly works better than its opposite.

</comment><comment><USER36> I am confident of the value I deliver but I don't call my competitors stupid. One person being correct or a winner doesn't mean others are stupid. Maybe some people can deliver value where the competition doesn't. Could be due to some leverage or insight or creativity.

</comment><comment><USER45> This is probably not a correctable problem. People don't start businesses if they think the competition is highly competitive and intelligent. They start a business of they perceive a weakness in the market, or believe they have a unique capacity to succeed.

</comment><comment><USER46> This works well when considering people in your own field, you know what it took for you to get there and you can assume they've had similar experiences.

However when you are considering the general public it is best to presume stupidity and design with that in mind.

</comment><comment><USER47> I've experienced this myself.

Sometimes what our competitors were doing was stupid, and we ate their lunch.

Sometimes what our competitors were doing was the only way to really run things, and we had to adapt to follow them.

</comment><comment><USER48> It is valuable to determine what technology, not available in the past, would cause a reasonable insider to change their decisions if they could implement that technology.

</comment><comment><USER49> Once again, xkcd explains all.

[https://xkcd.com/277/](https://xkcd.com/277/)

</comment><comment><USER50> Really? Is that the way some people reason about their competitors? Something like: "Oh, I guess they're just stupid and we're so smart."

Who in their right mind would do such a thing. Even if the competitors really are stupid (who knows?), it doesn't give you any advantage to assume that.

<comment><USER51> Ah, metaness!

So can we assume people who assume other people are stupid, are stupid? Or is there some benefit from doing things that way that might not be apparent at first sight?

One possibility that comes to mind is the substitution of parallelism for serial processing, or put another way, letting the world be its own model. Instead of one startup spending a lot of time thinking and researching (and maybe missing the market window if there was one), let ten startups just assume and go for it. Maybe nine will be wrong and fail and one will be right and succeed.

<comment><USER50> > Instead of one startup spending a lot of time thinking and researching (and > maybe missing the market window if there was one), let ten startups just > assume and go for it. Maybe nine will be wrong and fail and one will be > right and succeed.

But that'd be something like evolution or anthropic computing. In order to find a solution to a hard problem, write down something. If it is not a solution, kill yourself. Conditioned on looking at anything at all, you look at the correct solution.

Or we could use the distinct advantage of humans and think about it properly.

</comment></comment></comment><comment><USER52> Those folks are just being introspective, that's all..

</comment><comment><USER53> Agree with the first 3 paragraphs so much, well put.

</comment><comment><USER54> see also: Sarah Silverman's bit on scientology and things that sound weird.

</comment><comment><USER55> A nice article to manipulate your competitors from doing a market survey!</comment>


Ask HN: What tasks would you outsource to a 'non-developer' for $100/m? - <AUTHOR> Hi HN,
I currently work full-time, but needing/wanting to supplement my income by an extra $1k USD/m.
What kind of potentially recurring tasks are high-value, non-technical (at least require no programming skills) that you would consider outsourcing to a freelancer?
Clearly a very broad question, but open to different responses.
I have some design skills, a lot of sales experience, and a lot of training/learning experience. <comment><USER2> Maintaining a research web crawler/spider. Every few days it is launched from a command line, after few basic checks are done to the previous batch.

</comment><comment><USER3> Can you please edit your question. Are you offering to work for a month for $100 or for a minute for $100?

</comment><comment><USER4> If you were willing to be paid commission I would think your sales experience could easily earn that.

<comment><AUTHOR> Any suggestions/advice on how that might work for an online/part-time arrangement?

I've only ever been in legitimate quota carrying roles as a consultant.

</comment></comment><comment><USER5> I could outsource content writing, data validation n sanitization, some primary research etc.</comment>


Newsweek's Dan Lyons quits blogging -- includes the full text of his five deleted posts - <AUTHOR> http://www.thestandard.com/news/2008/11/18/real-dan-lyons-quits-blogging-over-yanked-blog-post

<comment><USER2> Sounds pretty angry to me. I don't know what the tone of his site was like in general, but maybe he needs to take some time off and cool down a little bit.

Life's too short to be constantly bitter toward people.

<comment><USER3> _Lyons slammed the company after Yahoo flacks told him just weeks ago that the Google/Yahoo search deal was a "sure thing" and that Jerry Yang wasn't going anywhere. "Then that deal fell apart. And now Jerry Yang is out on his ass. The take-away: Do not believe a word that Yahoo says. Ever."_

Then again, getting lied to constantly by PR people isn't exactly something that's going to result in happy feelings.

</comment></comment><comment><USER4> What's wrong with calling out PR people when they lie? I get why it's not good from the publisher's standpoint, but if they PR guys at Yahoo! are making stuff up constantly, call 'em liars.

</comment><comment><USER5> Once Fake Steve Jobs was unmasked, it was all downhill from there. The strain was already becoming evident...

<comment><USER6> It's a shame, because he was an incredible blogger. FSJ is the blog that I point people to as a sign of what Internet writing can be.

<comment><USER4> the guy IS an incredible blogger. He's just gotta find a new gig that lets him harness those skills again.</comment></comment></comment>


Ask HN: Why nobody talk about age discrimination in silicon valley? - <AUTHOR> <comment><USER2> If you search for "age discrimination" on HN, you'll find several discussions. For example:

[https://news.ycombinator.com/item?id=19100129](https://news.ycombinator.com/item?id=19100129)

[https://news.ycombinator.com/item?id=15974603](https://news.ycombinator.com/item?id=15974603)

[https://news.ycombinator.com/item?id=15525814](https://news.ycombinator.com/item?id=15525814)</comment>


Why are we still using Mainframes? - <AUTHOR> Why are we still using Mainframes? Do we have any alternatives? How easy is it to migrate? <comment><USER2> In my experience, mainframes tend to be used where functional requirements are very slow moving and reliability trumps flexibility.

I don't know of any case where a mainframe couldn't, in principle, be replaced by a server farm. However, maintaining a sufficiently reliable and secure server farm is a specialist job too so the benefits aren't always clear cut.

Ease of migration is really down to what the mainframe is doing and for how long. In practice, they tend to be in place for a number of years in hub-type roles e.g. general ledgers, payment systems. That sort of thing. The effect is that extricating them is extremely complex and expensive.

However, these issues aren't really limited to mainframes. We have the same problems with trying to extricate Sparc Solaris applications. We generally want to replace them with Lintel as we use them in most applications. But doing so is horribly complicated as they're embedded in byzantine flows that few understand and the systems often assume a level of hardware reliability that commodity boxes don't have.

<comment><USER3> Similarly this is why, in some places, people report having "that old XP machine running <software> in the closet" because <software> is really important to them and they have no path forward (it doesn't support > XP, it's actually too vital - though that seems like an odd reason not to update, etc.).

You could replace these things with something newer but the concerns by various parties can outweigh the willingness to fight and you probably don't want to be on the receiving end of "I told you so".

<comment><USER2> The XP factor is another good reason why people stay on mainframes. They tend to be supported forever, or as near as dammit. You don't get that (quite reasonably) with consumer grade software and hardware.

<comment><USER4> Also, IBM Z series provide full backward compatibility [1], so you can have new hardware and still run your COBOL program from 1976 with no issues.

[https://en.wikipedia.org/wiki/IBM_System_z#Architecture](https://en.wikipedia.org/wiki/IBM_System_z#Architecture)

</comment></comment></comment></comment><comment><USER5> >> Do we have any alternatives? How easy is it to migrate?

Oh god, no, don't even think about it. It's hard enough migrating away from a code base in Java, written 10 years ago and that runs on pretty much anything. Imagine how hard it is to migrate from a code base written in languages known best by engineers in retirement, that only runs on extremely expensive supercomputers made by almost a single company (IBM).

But the worse thing is that you can't just pull the guts out of the software that runs all the transactions of huge financial organisations. You can't just throw a switch and stop all financial activity in a big bank, while you swap a new system in place, because every second of downtime costs millions. Millions! Who is going to take the responsibility for that?

So change never happens because nobody dares make it. One day mainframes will outlive the last people who can program them competently and then we'll all be in trouble.

<comment><USER6> <You can't just throw a switch and stop all financial activity in a big bank, while you swap a new system in place, because every second of downtime costs millions.>

It's been done. Design and implement a replacement system, run it in parallel for a meaningful timeframe, then switch over. You _need_ a parallel implementation simply as a "hot backup" in case your primary system fails for whatever reason anyway, and it's easier to implement real-time redundancy in current systems anyway. (This was the niche that Tandem Computers served.)

I think most mainframes in the USA are used to run old legacy systems that will be needed not much longer (or that's the _plan_ , anyway), like shop- order control for old weapons systems -- tasks for which no replacement system would be necessary because the need ends with the project.

<comment><USER7> Without disclosure of past employers: huge international banks still use mainframes. Regular employees access them via custom software to flip data left and right as necessary. In my experience, penny-grabbing and a lack of will to push to new technologies is what keeps these system alive. It is not in the interest of anyone to make change happen. Management is there for their annual bonus, not their 10 year goal to spend money substituting systems that are working 'fine' in the here and now. That is not how you make a career in these institutions. See Dilbert for more information.

<comment><USER6> I really can't imagine that cost is a factor... it _has_ to cost _more_ to support a mainframe environment (especially assuming the need for a raised- floor, Halon-protected, chilled computer room and oversized, power-hungry peripherals) in anything but the shortest term.

</comment></comment></comment></comment><comment><USER8> Because changing code and process is hard.

I worked at a place operating a Unisys mainframe running code written mostly from 1972 through 1985. That "mainframe" is probably a 4U Xeon with an emulator running on it. There have been active projects (and easily a billion spent) to replace that mainframe since at least 1996.

Remember that mainframe systems mostly automated totally manual tasks, so businesses were literally built around them. The use cases left are mostly core applications like general ledgers, rules engines for big complicated processes, etc. They work pretty well, and most of the modernization budgets get spent replacing supplemental systems running Solaris, Windows, etc that are aging less gracefully than the mainframe.

</comment><comment><USER9> I think it is because it is the easiest/cheapest way to reliably handle a fuckton of transactions. So it's great for a bank. I can't think of any other use cases though.

</comment><comment><USER6> Legacy code bases.

I wonder how much of my 1986 code is still in use.

<comment><USER10> Out of curiosity: what did you write in the 80s?

<comment><USER6> That was in the defense industry; if I told you, I'd have to kill you... and everyone else reading. That's too much work.

</comment></comment></comment><comment><USER7> Vendor and code lock-in, mainly.

</comment><comment><USER4> Why? Because they work.</comment>


Microsoft's Sinofsky responds to complaint over Office 2013 on Surface RT - <AUTHOR> http://www.zdnet.com/microsofts-sinofsky-responds-to-complaint-over-office-2013-on-surface-rt-7000006484/

<comment><USER2> I had the same typing performance issue when using the preview version of Office 2013 that shipped with my Surface RT, updated to the RTM version today, and the typing performance is fine now. The characters even appear with a quick reveal-from-left-to-right animation now, that keeps up with my fastest typing speed.

<comment><USER3> Good to know the problem is gone.

How does the animation feel like after an hour of use?

<comment><USER4> It's the same thing on the x86 version, I found it strange at first, after a couple of days its just faded into the background and I don't notice it.

Video of the effect here <http://youtu.be/ddwo-AN2SmU>

<comment><USER5> I find it still messes up my rhythm a bit; the distraction might be slowing my typing speed down during a burst. Is there an HCI principle going on in this feature or is it just eye candy?

<comment><USER4> From my searching I can't find any practical reasons for it other than eye candy. It seems the only way to disable it is via a regedit

[http://www.winsupersite.com/article/office-2013-beta2/office...](http://www.winsupersite.com/article/office-2013-beta2/office-2013-tip- disable-animations-143779)

</comment></comment></comment></comment></comment><comment><USER6> It's ridiculous that a journalist writing technical blogs didn't even check that his Surface was fully patched. That's the first thing you should do with any system. I don't own a Surface so I don't know whether Microsoft told users to update their Surface shortly after starting it up, but they definitely should have so that these types of articles don't get published.

<comment><USER7> I just bought a Surface from a Microsoft Store today, and the store assistant not only told me there were updates available but showed me how to update it. So they're definitely making a pro-active effort to encourage people to update where possible.

<comment><USER6> I imagine that if it's anything like any version of Windows to come out since XP, or possibly even earlier, that updates are one of the first things that are presented to you post-install.

<comment><USER5> It doesn't seem that this is the case this, its even obscured as an optional update. See the linked article for more information.

<comment><USER8> 'Obscured' isn't the right word. It's business as usual for office (and other non-system) updates to be under the 'Optional' category..

<comment><USER5> One place to update apps on a system would be nice. I know windows as lots of legacy, but how many apps are optional system updates on windows rt?

</comment></comment></comment></comment></comment></comment><comment><USER9> Anybody who shares their opinion should consider these points:

1\. The office on surface is not the final version of software. It has RTM'ed so it should get updated with the final version pretty soon.

2\. The fact that you have an ability to run a program like office on a tablet class hardware and ARM architecture is in itself a feat of engineering and Microsoft should get some credit for that here. I was dying to put this louis CK piece in the comments: <http://www.youtube.com/watch?v=KpUNA2nutbk>

<comment><USER10> > The fact that you have an ability to run a program like office on a tablet > class hardware

This is an extremely misleading statement. "Tablet class hardware" today is vastly more powerful than PC's several years ago which were quite happily running the Office of their day.

Furthermore, there is plenty of Office-like equivalents happily running on Android and iOS tablets today so the suggestion that "Office on a tablet" is some kind of revolution seems to lack substance.

<comment><USER9> I was referring to ARM as the architecture. Should have been clearer

<comment><USER10> Sorry, but I still dont understand your point. Dual/Quad-core ARM chips of today running at 1.5Ghz blow away x86 based PC's from several years ago (I don't know exactly at what point) that ran Office XP quite happily.

To give you an idea, the system requirements of Office XP was "a Pentium processor with a clock speed of at least 133 megahertz (MHz)".

Besides, tablets are doing amazing things today, are we really saying an Office suite represents the pinnacle of computing power?

<comment><USER9> In case you are not trolling, time to educate yourself with the difference between these two architectures: [http://www.brighthub.com/computing/hardware/articles/107133....](http://www.brighthub.com/computing/hardware/articles/107133.aspx)

Surprise, if you copy an old mac app on your iPhone it won't run!

<comment><USER10> No, please, why don't _you_ educate us all as to the deficiencies in ARM over x86 that make porting an x86 application to ARM some incredible achievement?

</comment></comment></comment></comment></comment></comment><comment><USER11> Error in the article:

 _Too bad, because he had already fallen in love with the software, going so far as to opine that the Surface RT "doesn't just compete with the iPad – it bypasses the iPad in many ways that are significant and valuable for me."_

Nitpick: He fell in love with the hardware, the software is the part he didn't like. That was his complaint.

And: No matter if an update was available on the first day. For a major release like that it shouldn't have come to this in the first place.

Note: Is HN being mentioned and linked on ZDNet such a big thing that it should be the title of the entry rather than what it's about? _- > (referring to old title - title has been changed)_

<comment><USER12> _And: No matter if an update was available on the first day. For a major release like that it shouldn't have come to this in the first place._

I'm somewhat confused by this statement. I've rarely heard it applied to other companies. Siri being in Beta at launch was largely forgiven on HN. Even a substantial portion of HN made excuses for the new Apple Maps (which if it wasn't listed as a beta, clearly was).

Google's second most popular product, GMail, came out of beta in just mid-2009.

Lets be real. The update was available on the FIRST day. The freakin' first day and you're complaining that it shouldn't have come to this?

On a site where the near pillar of virtually every company is to ship something that, for all intents and purposes, is barely usable on day one and iterate like crazy, it seems like an odd statement.

I have to admit that I'm probably an odd beast in that when I get a new device, I actually install the latest software. Whether its a BluRay player or a computer. I get that most mainstream users won't do that, and I get that it was likely a mainstream blog, but I'd expect better of HN readers.

In fact I'd argue if you buy a device and it does not update out the box that's probably NOT a good sign of active development on it.

<comment><USER11> First of all:

My comment does not necessarily reflect the opinion of all individuals that gather here on HN.

Therefore:

Yes, i was a critic of Siri when it first came out and also of Apple Maps.

Additionally:

You might, and things like this happen with written text, over emphasize my statement. It was by no means meant as harsh criticism, but you can't deny the fact that it _shouldn't have happened_ and that was basically all i said.

-) why do updates not appear for some users (it was not just him)

-) when it's being marketed with running Office and then comes along in this condition, then it certainly isn't perfect

AND:

When also keeping in mind, that:

-) the Hardware seems to be astonishing

-) Design, Input methods, everything gets positive reviews

-) this a big milestone for Microsoft, showing off not only a Microsoft branded device (not just some device where their OS is running), but also a completely new direction in which they are heading

then this was not at all a perfect start, no matter how you put it.

</comment></comment></comment><comment><USER13> Kudos to the journalist for linking back to the comments.

</comment><comment><USER3> Very few loves writing documents on a tablet. Most love games, musics, books, videos. If MS focus on selling office on RT, it will be a disaster for the product, and for the company. For long documents it's going to be slow no matter how they optimize it -- we all know word is not that fast even in a desktop computer, and now they even have issues with a two-page document.</comment>


Why Did Steve Jobs Die? - <AUTHOR> http://www.drmcdougall.com/misc/2011nl/nov/jobs.htm

<comment><AUTHOR> Here's a quote from the article to intrigue you, "Jobs would have been pleased to hear my challenging second opinions about his pancreatic cancer and his diet, because my thoughts are in agreement with what he intuitively and factually knew to be correct. Hopefully, my account will bring some peace of mind to his family and friends after his untimely death."</comment>


TLS 1.3: Slow adoption of stronger web encryption is empowering the bad guys - <AUTHOR> https://www.helpnetsecurity.com/2020/04/06/tls-1-3-adoption/ <comment> chupa-chups [https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers- yet...](https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/)

[https://tools.ietf.org/id/draft-camwinget-tls-use- cases-03.h...](https://tools.ietf.org/id/draft-camwinget-tls-use- cases-03.html)

[https://www.nccgroup.trust/uk/about-us/newsroom-and- events/b...](https://www.nccgroup.trust/uk/about-us/newsroom-and- events/blogs/2019/february/downgrade-attack-on-tls-1.3-and-vulnerabilities-in- major-tls-libraries/)

Let's agree to disagree.</comment>


Researchers Rush to Test Coronavirus Vaccine in People- No Animal Trials First - <AUTHOR> https://www.scientificamerican.com/article/researchers-rush-to-test-coronavirus-vaccine-in-people/ <comment><USER2> I'm perfectly fine having it tested on humans - this is apparently the worst virus we've encountered so far so why not skip the lengthy animal trials and just skip straight to humans?</comment>


Ask HN: Best way to deliver research to 100+ Hedge Funds and Mutual Funds? - <AUTHOR>

We are currently distributing our research as emails; our client is Microsoft Outlook 2010 and we have a hosted Exchange server.  There must be a better way!
I'm interested in reducing latency, and moving to a solution that is actually scalable (right now we cannot send a single email to more than 100 recipients, and we are capped at 1000 emails per hour).
What are your thoughts? <comment><USER2> Google mailchimp, aweber to read up on them. Email me if you are in NYC and I can show you the ropes.</comment>


So long, silicon: Researchers create solar panels from cheap copper oxide - <AUTHOR> http://www.extremetech.com/extreme/134305-so-long-silicon-researchers-create-solar-panels-from-cheap-copper-oxide?utm_source=rss&utm_medium=rss&utm_campaign=so-long-silicon-researchers-create-solar-panels-from-cheap-copper-oxide <comment><USER3> The takeaway from this article is that they came up for a technique to use cheaper materials instead of silicon. This is significant because silicon is very expensive and every increasing demand is also increasing the prices of it at a very fast rate. I took a class on CMOS Digital Design where the professor went over manufacturing overhead for a processor. The cost of the silicon alone was astounding, not even taking into account all the other overhead that comes with the process.

Unfortunately, like a lot of other research in this field, its real world applicability may be relatively limited. One of the reasons for this is that so much time, money, and infrastructure has been put into modern silicon semiconductor manufacturing that no one really wants to touch anything else. It could mean starting from scratch and requiring massive amounts of R&D and process planning to break even.

The real breakthroughs come when someone keeps the existing silicon process in mind and makes discoveries that use the existing infrastructure. That's the kind of research that really "changes" things.

If someone could come up with a manufacturing system that was cheap and easy to swap out or modify the process, they could literally change technology as we know it. If you could have the capability to scale processes easily, a lot of the really cool and cutting-edge research could get implemented on a large scale.

EDIT: I graduated as an electrical engineer and have taken several clean room processing classes, in case you were wondering.

<comment><USER4> From what I've learned, silicon is abundant in the earth crust. The problem is that you need a very very high purity to make useful wafers. So technically, its not a problem of scarcity, just a lack of miners producing it in a very pure form, which could be solved by having more of them.

Are there some other difficulties that I'm overlooking?

<comment><USER3> It's expensive to manufacture silicon at semiconductor quality, even when talking about polycrystalline wafers. (Monocrystalline wafers, used for "chips", is even more expensive and prone to defect." People are increasing production of polycrystalline silicon wafers but the demand is much greater than the supply, even with this increase. The cycle basically goes like this: polycrystalline gets more expensive because of demand -> supply increases -> prices go down (in theory) -> demand increases -> polycrystalline gets expensive again.

This is an endless loop right now, as the total amount of possible demand is >> than the growth of polycrystalline foundries. Furthermore, LCD displays also use this form of polycrystalline silicon, which doesn't help with the demand problem. Decently-graded silicon is inherently expensive to manufacture because of the process involved.

The takeaway is that if these metal-oxides are cheaper to produce, even if they are more expensive for the raw material, the cost savings would carry over to the products. Equally relevant when talking about solar cells is how much energy is needed to produce the cells themselves. Right now, an enormous amount of energy is required for silicon solar cells. Helping the energy crisis doesn't help if something takes that much energy to produce. (I do not know the ratio of lifetime energy output versus energy to manufacture but I am sure it's not very good.)

<comment><USER5> Again, you have this 180 degrees backwards. There was a huge rush to build out polysilicon module fabs in China that has caused a huge oversupply. Now module manufacturers are going out of business daily, leaving an oversupply of polysilicon capacity.

Here, from a few days ago:

[http://www.pv- tech.org/news/polysilicon_headwinds_unchanged_...](http://www.pv- tech.org/news/polysilicon_headwinds_unchanged_at_hemlock)

<comment><USER3> That's really interesting. The industry is in a different place compared to when I was familiar with it.

</comment></comment></comment></comment></comment><comment><USER6> Source article (not so breathless and a more reasonable title): [http://arstechnica.com/science/2012/08/discovery-opens- door-...](http://arstechnica.com/science/2012/08/discovery-opens-door-to- cheaper-solar-panels/)

<comment><USER7> And no OnSwipe, either, thanks.

</comment></comment><comment><USER8> Disclaimer: I am not a physicist, and most of this is from memory relating to DIY experiments ~2 years ago.

* Copper oxide panels are not new.

* They are much less efficient than silicon panels.

* Cu2O is much more expensive than silicon.

<comment><USER9> That's what I thought as well. Silicon is basically.... well, sand, isn't it?

<comment> Tuna-Fish Going from sand to pure polysilicon is extremely energy-intensive and expensive.

<comment><USER10> It's not terribly energy intensive. You want to see energy intensive, pick up a beer can. Aluminum is electricity in solid form.

Silicon is capital equipment intensive. It is processed in batches. While each batch is being processed, it ties up an expensive processing station for a long time.

<comment><USER11> 1 pound of metallurgical grade silicon takes about 1 pound of coal and 1 pound of wood chips.

1 pound of polysilicon takes about 2 pounds of metallurgical grade and even more energy.

1 pound of wafer takes about 2 pounds of polysilicon and even more energy.

Aluminum probably doesn't take as much energy but the difference is Silicon's energy is cheap (coal and wood chips for the first step).

<comment><USER12> Isn't the reason that silicon is cheap to process is because there are high- silicon sands at Silicon Valley and other places?

By the way, would a solar furnace be feasible to replace your first step, eliminating CO2 result?

<comment><USER11> I'm sure you didn't mean it as such, but that's actually kinda funny; no, Silicon Valley did not get its name from the manufacture of Silicon from sand. Most of the sand that is sourced to make your microchips and solar cells comes from quartz mines and sand pits in Appalachia; Alabama, SE Ohio, and West Virginia are probably the top producers. Silicon Valley imports wafers and has historically had very little to do with how those wafers got made.

In fact, according to the foreman at one of said plants I talked to, they use pieces of quartzite that are more like pebbles than sand; no point in crushing it further I guess.

The function of the carbon is not just to create the heat but also to give the oxygen some way to remove itself. In fact, I believe the oxygen would still rather bond to silicon than carbon but the carbon is able to pull enough physically away as gas to make the reaction work. The resultant gas is mostly CO, carbon monoxide, which somehow becomes CO2 after the plant's done with it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> This article is really very wrong about conventional solar cell manufacture - especially the "Almost every solar panel..." paragraph. Here's a decent resource on standard manufacturing technology: <http://pveducation.org/pvcdrom>

</comment><comment><USER14> How about we mine mars to make solar panels from Iron Oxide? Or bring machines to mars that will build solar panels?

Then we could have an entire electrical power source for human habitation or machine experiments.

<comment><USER15> As it stands, we have not yet built a factory using exclusively robots. I'm sure that this would have very useful applications on Earth, as well as on Mars, if you were interested in tackling it :).

<comment><USER12> If you want to start somewhere: <http://phys.org/news/2010-12-sahara-aims- power-world.html>

</comment></comment></comment><comment><USER16> I found the picture humorous, reminded me of so many post holocaust games, unfortunately it also reminded me of some cities I passed through that border the Ohio river.

<comment><USER17> Post-apocalypse, not post-Holocaust

<comment><USER18> "a great or complete devastation or destruction, especially by fire" - <USER2>

<comment><USER19> I'm glad I'm not the only one who has to do something when someone corrects a person, but is wrong themselves. One of my BIGGEST pet peeves!

<comment><USER7> I would still bet the OP actually meant apocalypse, even if their mistake turned out sorta correct. "Post-holocaust" is a rare usage.</comment></comment></comment></comment></comment>


The Race to 10/7nm - <AUTHOR> https://semiengineering.com/racing-to-107nm/ <comment><USER2> This post is incredibly frustrating to read.

> _" companies A, B, C, and D are producing w, x, y, and z nm transisters"_

> _" you have to ignore what nm they used, because actually w nm = x/2 nm"_

> _continues to use company-specific nm instead of comparable units_

> _reminds you again that the numbers are not comparable_

> _continues to use company-specific nm instead of comparable units_

> _"We've also packed them closer together to improve transistor density," > said Kaizad Mistry_

Yes, that is what density means. Very good!

> _" And forming the gate itself is also challenging. "Cycle times are > increasing for this step, driven by the complexity of the stack," said > Mohith Verghese, director of global product marketing at ASM International. > "The metal gate stack is also getting very complicated."_

Oh, it's getting challenging, complex, AND complicated!

> _There are several layers in the metal stack._

I think you just told me that a stack of something has several layers. Also that the metal gate stack is metal.

> _And issues, such as... all add to increased cycle time."_

So cycle times are increasing because issues lead to increased cycle time?

...

gah. I want to finish this, but it's just so hard to read a pile, with several layers of course, of redundant PR snippets.

...

> _performance become limited, mainly by the contact and back-end-of-line, > because those become the bottleneck."_

FFFFFFUUUUU

Christ on a cracker, get an editor. Oh...you ARE the editor. < _cries_ >

<comment> semi-extrinsic There's lots of fun here!

 _> It will cost $271 million to design a 7nm chip, according to Gartner._

Not a million more, not a million less.

<comment><USER2> > _As the size shrinks, less and less area and volume are available_

Wait, are you sure?

<comment><USER3> Unclear. Sometimes a smaller size like 7nm is actually 10nm. To summarize 10 > 7 BUT 7 = 10.

<comment><USER4> > Cost, of course, is key because only a select group of foundry customers > with deep pockets can afford 10nm and 7nm

Really? I wouldn't have known that only people with more money can spend more money

</comment></comment></comment></comment></comment><comment><USER5> All the node names are effectively useless now. A good rule of thumb is that TSMC 7nm ~= Intel 10nm and they're shipping at approximately the same time.

<comment><USER6> And last time I checked into it, neither has much to do with 7 or 10 nanometers. The 'feature sizes' of old are not actually on that scale, rather it's more a measure (read: marketing speak) of resolution than of feature size at this point? I still can't get good answers. As a biologist used to working with objects that actually do have features on the order of 0.1nm, and volumes with less than <5nm per side, I'm trying to figure out just how big these transistors really are to fit into my existing mental models. At what point do the transistors actually have to start dealing with (can they deal with) quantum/thermal/structural effects of being so small.

<comment><USER7> > At what point do the transistors actually have to start dealing with (can > they deal with) quantum/thermal/structural effects of being so small.

I think that was about a decade ago. These things simply cannot work if they ignore the quantum effects at their size.

<comment><USER6> I guess the better way to ask is when do those effects dominate rather than merely effect. At what point do structure and feature type need to actually change?

</comment></comment></comment></comment><comment><USER8> It's exciting to see such an incredible rate of advancement; I can't wait to see what transistors at 7nm and less will make possible. I can still remember when these same components were measured in millimeters.

<comment><USER9> Chips that are just like the ones we have now but 30% cheaper? I don't see how this is going to open up whole new technologies that weren't possible at 10/15nm.

<comment><USER10> Yes, we need technology that increases CPU clock speed above the current plateau.

<comment><USER11> Why do you think we need to increase individual clock speeds past their current limits?

<comment><USER12> due to Amdahl's law, it's always better to have a single faster processor than multiple slower ones.

...but do we really need faster processors? i don't know, but i'd like to have one :)

<comment><AUTHOR> It's easy to think we need faster processors when the architectures we use, both software and hardware, are incredibly inefficient.

Any modern processor is _much_ faster than the RAM its programs and data live on, hence the multiple levels of cache inside them. Multi-cores add the complexity of keeping the memory consistent. Multiple threads per core put additional pressure on caches while our OSs assume all processors see a unique and consistent memory image (which requires keeping caches consistent across cores). Our most common software doesn't run on GPUs before extensive changes. Only mobile platforms are exploring asymmetric multiprocessing with a single ISA now.

I don't think we need faster single-thread performance. What I think we need is to adapt our software, which is designed to run on ridiculously fast copies of ancient personal computers, to run on computers that instead of mimicking a successful product of the 80s resemble more what we _can_ do now. We need software that exploits the SIMD units (predicate bits that prevent branches are your friends there), that runs well in multiple cores and OSs that can deal with memory inconsistency between cores (maybe using write-through instructions for shared data and write-back for process-local stuff). We need software that doesn't need complicated instruction reordering or speculative execution.

</comment></comment></comment></comment></comment></comment><comment><USER13> My understanding is that the actual pitch is not getting considerably smaller, despite the (still fairly large) changes in quoted node size.

Also the cost per wafer for TSMC 20nm is still the same as when TSMC 40nm was introduced, the latter today is about half as much money, AFAIK. 16nm is about half way between the introductory price of 20nm.

The transistors are getting slightly smaller, but the cost per transistor seems to be staying the same or increasing; Moore's law really died like... a decade ago.

These days you see us coming to terms with it. For years we've been telling people that computing resources are abundant and they needn't worry about memory or CPU time because their application will double in speed in a year. This is probably why most websites are awful these days, and take more time than ever to do things they did nearly 20 years ago in half the time.

</comment><comment><USER14> Once you get down to 7nm don't quantum effects become harder to deal with? Don't know much about chip design but I seem to remember as things get really small it gets harder to isolate components.

<comment><USER5> Yes, quantum tunneling is a real problem and has been an increasingly dangerous issue as the nodes shrink. Three interesting proposals to try and mitigate the issue are:

1\. TFETs, aka Tunneling FETs, harness the leakage current itself to drive the transistor.

2\. Quantum well FinFETs, use the quantum well to constrain the electron movement and circumvent the problem.

3\. This is more of a stopgap measure, but the usage of SiGe FinFETs with FD- SOI.

</comment></comment><comment><USER5> Also apparently GloFo is developing its own 7nm process (its ancestry was at IBM before GloFo bought them iirc) but _not_ licensing Samsung like with 14nm.</comment>


What not to ask technical people in interviews - <AUTHOR> http://www.fusioncube.net/index.php/what-not-to-ask-technical-people-in-interviews <comment><USER2> "The dirty little secret that I don't mind saying is that software development isn't hard. There's lots of handbooks, manuals, blog entries and Stack Overflow Q&A pages out there that very clearly describe how to work with any development language or tool. Follow it step by step and you are a software developer."

Great, yet another article continuing the tradition of thinking software development is an easy discipline, but it's our mindset that makes us special.

Good luck developing anything mission critical with a team of low paid googlers.

One day even people in our profession might come to actually have some self- respect for what we do. Software development is a hard and challenging discipline - to trivialize it by pointing at guide-books and Q&A forums just demonstrates a total lack of understanding for what we do.

<comment><USER3> > Good luck developing anything mission critical with a team of low paid > googlers.

IMHO, that's another dark-secret of this trade, most of us don't develop "mission critical" services. By "mission critical" I understand something like "if this code breaks then someone dies or huge sums of money are lost etc.".

> One day even people in our profession might come to actually have some self- > respect for what we do

I totally agree with you that "software development is hard", but not because someone happens not to know what methods a standard library class implements (every few days I give almost god-like thanks to the developer that decided to implement the dir() function in Python), but because ~35 years after "The Mythical Man-Month" was first published we repeat at least half of the mistakes presented in there.

<comment><USER4> Yup, I agree.

Software engineering also requires a lot of mental pain, and struggling and debugging, but the end result? it's equal to what other occupations produce with less struggle.

</comment></comment></comment><comment><USER5> Wow, that is quite an article. I think it manages the rare feat of being completely wrong. Usually people write enough words that they stumble into saying something useful.

Personally, I love asking esoteric questions in interviews, but not because I care about that particular question. I am trying to figure out if you are the kind of programmer who looks beneath the covers to figure out what is really going on. Do I expect every programming to know how b-trees relate to database indexes, and what their lookup times are, no. But if you have written a lot of SQL and never bothered to figure that out, you are probably a slave to the SQL interface and aren't the type of person who will ever really understand how to optimize queries. The point is to figure out they type of person they are.

Secondarily, I like working with nice people. It's important. But I have worked with nice and smart people who wrote horrible unmaintainable code, and I ended up loathing working with them. Plus, the better the programmers, the less of them you need. Turns out this is terribly important in software.

<comment><USER6> I think, though, that it's wrong to decide "this person is not intellectually curious" merely because he has never investigated the particular esoteric bit you picked to test "intellectual curiosity".

I could ask you if you know the x86 calling conventions--what, you don't know? But you use x86 machines every day, and write code to run on x86! You're obviously a slave to Ruby/C++/<insert-language-here> and just aren't the type of guy to go learn things.

<comment><USER5> Like I said, I'm not trying to find out if you know a particular thing, I'm trying to figure out if you ever learn things that are deeper than the surface. So, if you don't know x86 calling conventions, fine. But if I ask several more questions in that domain, and you don't know any of them, then I check your resume and you having been writing C level code for years, I'm concerned.

</comment></comment></comment><comment><USER7> Actually, I'd say the #1 thing not to ask me in an interview is "What is your passion?".

Did you really want to hear about my time between the sheets with my wife? No.

Did you really want to hear about my love of outdoor Humans vs Zombies games, or the different kinds of Munchkin games? No.

You probably wanted to hear about my work as a hobbyist Computer Science researcher, but I don't want to tell you about that. You would understand half of it and then decide that I'm a grad-school egghead who doesn't belong at your company.

Luckily, I applied to graduate school this year.

<comment><USER2> The people who ask what your passion is and are looking to hear that you program for the heck of it are simply trying to cash in. Likely you'll be willing to work longer hours and get paid less then your knowledge is worth because you'll get to work on "exciting and challenging stuff!".

I've met several people who think this is the only way to hire "real" programmers. They never get it when I point out that no other profession operates in this manner.

<comment><USER8> What these same people also fail to realize is that just because you enjoy working on "exciting and challenging stuff!" doesn't mean you will find debugging their firm's spaghetti code exciting.

Yes, there are projects on which I would work 10-15 hours a day with minimal pay but, odds are - yours isn't one of them.

</comment></comment></comment><comment><USER9> tl;dr; I only ask detailed questions about technologies of which a candidate claims recent and deep knowledge. Wrong answers suggest stupidity or dishonesty.

Let's say I'm interviewing someone who claims to have been a professional software for a decade and that most of his work was in Java. I know Java quite well, and I know what sorts of things one HAS to know about Java if he doesn't fundamentally suck as a software developer and isn't lying on his resume. If you claim to have written Java code for the past five years but can't explain the difference between a Set and a List, you are either stupid or dishonest. One of my favorite questions for a supposedly experienced Java developer is to show them a code snippet with a try/catch block and ask them to trace through the code's execution in both the case where an exception was thrown and the "happy path". Roughly 40% of the people I've interviewed who have claimed years of recent Java experience (like they were coding in Java the day before) think that a method's execution terminates when a catch block is entered and that block's code finishes executing! How could one possibly write correct code without understand this? How much evidence to the contrary must they have ignored? One developer complained to me that my question was hard because he was "mostly used to dealing with SqlException and not other exception types." He then complained that he was an experienced Java developer and didn't see how my question was relevant to the job for which he was interviewing. Want him on your team?

<comment><USER10> Aha,

Here is the problem. The days of deep reading and understand and learning are behind us. IDE's really know what is good for what situation and just autocomplete whatever is appropriate. The days when you had to read the manual at every unknown point and besides text based autocompletion in Emacs/Vi no other help from IDE's are long behind us.

Most programmers todays are all about such things. In other words and putting it very directly. Productivity has become an order of an magnitude more important than knowledge and intelligence.

That is partly also because a lot of work needs to be done today than it was a decade back. And when the ecosystem grows at such a rate tools to enable the common folks program get invented.

These days its all about productivity.

EDIT : Downvote this as much as you like, but more the frameworks and more the intelligent IDE's get. Lesser and lesser significant our jobs become.

In fact to an extent they already have.

<comment><USER11> The more my IDE does, the more I am expected to do above and beyond what the IDE does.

<comment><USER10> The areas above and higher your IDE are/will be little to do with math and bit shifting.

They will be more and more of domain knowledge and understanding the problem on hand and little and little to do with worrying and learning arcane facts behind the scenes.

Some applications may need it but most won't.

<comment><USER12> How do you figure that knowing the execution path for a basic language feature is an "arcane fact behind the scene?" This is equivalent to not knowing how an if or for statement works. You can't write ANY code without this knowledge.

<comment><USER10> How were we able to understand try/catch while all we had known is return statements from functions and error checking through flags?

How were we able to understand if/else statements now, while all we were able to understand jmp and goto statements earlier.

How can people work with Microsoft excel without actually knowing they are into databases and functional programming?

First you learn how to use a logical block of programming, then you learn many other blocks. Then you learn how to use them together. Then many interacting blocks come as a pre packaged solution to a lot of problems. Assembling those blocks comes in the forms of of IDE's. That is how we have managed to move from bits, to assembly language programming, to languages lisp, C and till now where IDE's do most of what we do.

If you had asked anybody 50 years back if we could have come this far. Their answer would be no. Same as many people today can't believe that programming can be done without actually writing code syntactically.

You can do a lot of network programming today or IO programming today without knowing anything about OS or deeper networking aspects. You could not have told the same thing 15-20 years back. The average skill required to achieve these tasks is only decreasing.

On an average scale the skills, knowledge and work required to be a good programmer over 50 years has only decreased.

In the future, the solution to a problem doesn't necessarily has to be a code.

Haven't we seen Yahoo Pipes and things like that?

I can understand this attitude that most people are showing, because it effects their bread and butter. But this is the natural progression in any discipline.

I doesn't take an army of farmers and cows to do farming today. Farming is far more productive today than it was 100 years back.

The same case will be with software. Like it or not, it is going to happen.

</comment></comment></comment></comment></comment></comment><comment><USER13> I've developed a simple set of questions to avoid these types of pointless interviews.

It was last tested about two weeks ago when I was casually talking with the founder of a local startup who wanted me to join his team. I politely declined the offer.

Here are the questions:

1\. What is your product?

If the answer to this is marketing talk, they fail the test.

2\. Who is your customer?

Same with #1, but add "everybody!".

3\. What is your development setup/rules/guidelines?

No source control? Bye.

Testing on production servers? Bye (this startup did that, and wondered why their app failed to work).

No workstations? You mean that I will use my personal computer at your office? Bye, Bye!

What language/framework/technology do you use? If the answer is PHP/in house MVC then I'm out. I dont mind PHP/MVC, but most are hacked up pieces of crap that can't compare to symfony or even code igniter/cakephp.

This allows me to consider working with people who know what they are doing, instead of wasting time with people who want to test me on what they think I know.

This simple test was developed after an interview with a local startup. The interviewer was the "software engineer", and he had pulled questions from project euler to test me. After realizing this, I ended the interview quickly. Their product? A web app for realtors to showcase their listings. Yeah, that required developers that were able to solve advanced project euler exercises.

<comment><USER14> It's hard for me to believe there exist companies that have the resources to hire software developers and that don't use source control.

<comment><USER15> You better start believing it, I've seen it... If you doubt my anecdata, check TheDailyWTF.

It seems to me that the problem is too many people see software development as linear and quality as monotonically increasing, i.e. just save your work and back it up.

</comment></comment></comment><comment><USER16> I was being tag-team interviewed for a programming job. The first guy asked me what I disliked about my current workplace. I said, "Nothing," because money was my only reason for leaving. He didn't believe I couldn't find one negative thing to say, and made bold marks (probably a big "X") on a paper. In the next interview, a lady manager asked me the same question. Not wanting to make the same mistake twice, I said, "Office politics," and sat back smiling, ready for the next question. She frowned and said, "Define office politics." I said, "Umm..habbadababbadah...gah..er," until she decided to move on to another question. I got the job!

</comment><comment><USER17> Start asking me about B-tree algorithms and my eyes will glaze over. However you can go and look inside my MySQL database tables and you will see a beautiful relational database. I enjoy computers/programming because going back as far as I can remember I have never run across a problem that I could not figure out with enough gray matter time. I really enjoy making stuff and solving problems, I used to do all of my math homework in my head and then have to go back and write out the solutions (for the teacher to check) just because I enjoyed solving the problem step by step.

TLDR: I build stuff, it works and I smile.

<comment><USER18> Not that I don't believe you, but I'm genuinely curious.

When you're designing a "beautiful relational database" without thinking about the algorithms behind it, how are you taking the performance effects of those algorithms into account? How do you know which relationships and queries are likely to be efficient and which are not?

<comment><USER11> Parent is talking about beautiful schema, not a beautiful query planner. If you are capable of understanding the concept of abstraction and encapsulation, you can design a good system knowing the performance characteristics of your components but not their internals.

The geniuses who wrote postgres don't know how to write responsive web sites. The geniuses who make gorgeous fast websites don't know how a Btree is implemented. It's OK. That's how the global economy works.

<comment><USER19> But the fast-website people still need to know what makes a query slow and how to improve it. They don't (and shouldn't) write their own database engine, but they need to know how their equipment works.

</comment></comment></comment></comment><comment><USER20> The deeper problem is that job interviews are irremediably broken. They are artificial to the point of stupidity. At least for the kind of work we do in software, there is no fixing them. They need to be thrown out and replaced with something else.

Working together is a kind of relationship. You don't interview for a relationship.

<comment><USER21> Sure you do - it's called a date.

After an interview/date, you then have (in the UK at least) a probationary period (going steady), and then a wait before a statutory period (engagement) before you are fully "employed" in law and can't be removed easily (marriage).

<comment><USER20> Your analogy confirms my point, because the things that make job interviews so awful are not things people do on dates - not without being crushingly inappropriate. What you're talking about, it seems to me, is contactful conversation. That's precisely what job interviews are not, and that's the problem.

In fact, the dating analogy points toward a saner way for small organizations (as most software teams ought to be) to find people. Get to know one another in a relaxed way. See if there are common interests and values. Do things together. Eat and drink. This is how humans behave.

There are other analogies to look at too - auditions might be one.

<comment><USER22> The problem is that it's much more costly to make a bad pre-hire, if that's what you want to call it, than it is to go on a bad date.

You can't just bring someone in and let them be their self in the office. You have to have someone onboarding their HR stuff, someone onboarding them on to the technical stuff, someone getting them a laptop and access to source control, someone answering their questions, someone tasking them with things. All this takes time away from people who could be making the company money.

You can start reducing these things (don't give them access to source control, give everyone the same initial tasks) but now you're just reducing it back to a job interview.

<comment><USER20> Maybe, but the status quo is a reductio.

What's the biggest problem for software companies right now? Attracting good programmers. That's true of startups, anyway, and as startups go so goes the industry. What that tells me is that those who get ahead of the curve and figure out how to grow teams better are going to have an edge. This is a big deal, and job interviews suck so badly that there is room for innovation.

</comment></comment></comment></comment></comment><comment><USER23>
      > "I'm an egomaniac who has spent vast amounts of time
      > Googling this nearly useless knowledge, but will ask
      > you to regurgitate it to me without the aid of a search
      > engine, and then judge you on how much it makes you
      > sweat.

He chose the example wrong. That list is really good — and the knowledge is far far away from being _useless_. Unless you want your "experienced" developer to spend hours trying to figure out, why layout is broken, just because he knows nothing about quirks mode and how doctype influences that. Or maybe you prefer your web app really slow, because your developer does not know about event bubbling and created and event handler for every single cell in your table, instead of having a single one? There are some questions over the top in the list, but most of it is pretty solid.

</comment><comment><USER24> Developers hire other developers that think like themselves.

Technically oriented developers hire other technically oriented developers.

A mediocre developer won't be able to distinguish who knows their stuff or not. But at least getting team fit / communication / personality right is half the battle.

</comment><comment><USER25> This spirit of the article is good, but two of the three example questions are bad. I ask candidates about projects on their resume. I ask them deeper questions about those projects. Many people get excited about cool things they have built and will tell me about all the details.

If you cannot clearly explain the interesting details of a project you should be familiar you are either not that smart, are taking credit for an entire project that you were only a small part of (this happens pretty often) or I am too dumb to understand the concepts (I like to think I am pretty smart and this never happens).

I also ask why they want to work here. Many people don't really know and that is OK. Many want to move into management, although they will never say it directly, and that is usually a red flag.

</comment><comment><USER26> Apparently, the one core qualification for software development is to write radical, but philosophical articles to no end about it.

</comment><comment><USER27> > _All these questions do is scream, "I'm an egomaniac who has spent vast > amounts of time Googling this nearly useless knowledge_

Quite the opposite. The original list of questions _is_ absurdly long, but it is an amazingly precise synthesis of what a good front-end developer should know. The three questions proposed are not nearly enough for hiring someone technical. You _need_ to probe for knowledge, that will make passion and interest surface.

</comment><comment><USER28> When interviewers start lobbing questions that have no relevance to what it means to be a programmer, just smile sympathetically and relax, act like you have just been informed you will be required to work with passionless programmers.

What will blow your mind is that you can ace these interviews without being able to write a line of code to save your own life. Just do what Ken Jennings does when he practices for jeopardy: memorize every esoteric fact you can find. This is not a small task, I built a Web app to store and randomly quiz myself on all potential questions in a domain. I have about 9000 factoids in there, I wow the pants off these non programmers, and made the mistake of picking a place that refucture the codebase and I have to scurry around to fix it or they will use their political connections to blame the problems on me.

After they are done playing jeopardy with you give them the Joel test, they will get a 3 or 5 of 12.

<comment><USER11> You cleverly designed a system to con your way into a job you knew you would hate? Congratulations....?

<comment><USER28> You just conned a comment into HN. How do you feel about that? And what is your view on loaded questions?</comment></comment></comment>


The History of Node.js - <AUTHOR> http://elegantcode.com/2012/02/06/solving-the-upload-progress-bar-problemthe-history-of-node-js/

<comment><USER2> Node.js is a great project and is making popular good things, but there is some disinformation in this blog post. For instance Tcl has had this idea of an http server that is an event based library for at least 10 years.

Not just tclhttpd, I mean, event programming in Tcl is central and there was a library called 'http' that exported a web server where you could bind urls to Tcl functions serving them.

<comment><USER3> > there is some disinformation in this blog post. For instance Tcl has had > this idea of an http server that is an event based library for at least 10 > years.

I think it was quite clear that he spoke of his personal change in thinking about what a web server was.

</comment></comment><comment><USER4> > The best thing about javascript on the server is that no one had used it

AppJet and Jaxer were around way before, as well as JSDB, haXe/JS, jslibs, Narwhal... that should read "no one had succeeded before".

<comment><USER5> Active Server Pages could be written in JScript (Microsoft's variation of JavaScript), and they even grew that into JScript.NET.

<comment><USER6> Didn't JavaScript start as Netscape's LiveScript intended to run on the Netscape web server? So more like it is coming full circle.

edit: random link sort of supporting what I thought I remembered <http://www.findmeat.org/tutorials/javascript/x486110.htm>

<comment><USER7> Yes! I remember waaaay back then thinking about starting a company that would develop a client side scrpting language like Visual Basic. But then Netscape started talking about LiveScript and I figured they'd be too hard to displace.

</comment></comment></comment></comment><comment><USER8> > (Ruby is f*cked because it can only run on one thread)

Also, surprisingly enough, Javascript.

<comment><USER9> Hilariously, while it's true about JavaScript, it is not true about Ruby.

<comment><USER10> Maybe they were referring to the MRI/YARV GVL? (even so, their claim is still not technically correct)

</comment></comment></comment><comment><USER11> I really enjoyed listening to this and it was especially helpful for me as somebody transitioning out of an academic environment like Ryan did before starting node.

</comment><comment><USER12> There is this really great (German language) podcast about node.js from a well known podcaster here Tim Pritlove: <http://cre.fm/cre167> \- I listened to it and I know I had to try out node.js (which I did).

<comment><AUTHOR> Can you write a blog on its content?</comment></comment>


Hack Later — A Hacker News Client for iOS - <AUTHOR> http://brushedtype.co/

<comment><USER2> Pretty nice. Good work! However, for a link browser only it's slightly expensive in my opinion.</comment>


Nsjail – A light-weight process isolation tool for Linux - <AUTHOR> http://nsjail.com/ <comment><USER4> This seems very similar to Bubblewrap: [https://github.com/projectatomic/bubblewrap](https://github.com/projectatomic/bubblewrap)

<comment><USER5> I don't see anything to suggest that nsjail has the main feature of bubblewrap: It is safe to make bubblewrap setuid-root, and therefore bubblewrap is a safe way for unprivileged users to use containers. (arguably the only safe way at the moment)

Without nsjail making that guarantee, nsjail is just yet another command line interface to namespaces.

</comment></comment><comment><USER6> How does this compare to firejail?

<comment><USER7> This tool is lighter-weight than firejail. nsjail seems to be a thin abstraction over Linux namespaces, while firejail contains profiles for common desktop applications and some X hackery to enable jailing of GUI programs.

<comment><USER8> author here:

Yup, nsjail doesn't have X hacks (I should work on that), though it offers some profiles for Apache-like type of applications:

[https://github.com/google/nsjail/tree/master/configs](https://github.com/google/nsjail/tree/master/configs)

I believe nsjail uses one of the most advanced (if not the most advanced) seccomp-bpf config language - kafel: [https://github.com/google/kafel](https://github.com/google/kafel)

<comment><USER9> bwrap allows passing a FD containing the seccomp rules (--seccomp FD w/ seccomp_export_bpf). If it can export the compiled eBPF it should be trivial to use kafel profiles w/ bubblewrap/atomic/flatpak/etc.

</comment></comment></comment></comment><comment><USER10> Is this what I should use if I want to intercept filesystem calls (and rewrite them, or generate on the fly the file that is about to be accessed)? Something else I should look into for this purpose?

<comment><USER11> It doesn't sound like NsJail does that; maybe try FUSE or SECCOMP_RET_TRACE?

<comment><USER8> Yes, SECCOMP_RET_TRACE works, but nsjail doesn't have code to support that - it didn't seem that useful when mount namespaces can police access to files.

Otherwise, it's possible to make it support that. Though, a word of caution: ptrace() is complex, and sometimes buggy interface with a lot of corner-cases - iow: it's easy to make a mistake with consequences for security of the whole setup.

PS: It's possible to use SECCOMP_RET_TRAP (TRAP(number) in kafel's - <USER2> seccomp-bpf cfg language - nomenclature), and rewrite syscalls in-process with help of SIGSYS signal handler.

</comment></comment></comment><comment><USER12> Is there a minimum required kernel version? How does it compare to proot?

We use proot in our build pipeline and it would be interesting to look into alternatives.

<comment><USER8> Re kernel versions: Depending on when CLONE_NEWUSER and seccomp-bpf were added to the kernel for different CPU architectures. For x86-64 it was probably around 3.16, for some others it might be even 4.3 (e.g. ppc64). It might even work with earlier versions if you use --disable_clone_newuser and avoid using seccomp-bpf filters.

Re 'proot'. I've never used it (it seems to be a configurator for the mount namespace), but nsjail seems much more advanced: cgroups support, seccomp-bpf via configuration language support, and a few more features (configs, net).

<comment><USER9> What about older LTS systems that have CLONE_NEWUSER but only allow access to it from uid 0?

<comment><USER8> You can run it as root, and specifiy users/groups to switch to before executing an app. Though, CLONE_NEWUSER was meant for exactly that - <USER3> namespaced without euid==0. Some systems like Debian have a sysctl flag:

kernel.unprivileged_userns_clone

which controls this behavior. Ultimately, it's up to you whether set it to "1", as CLONE_NEWUSER in the past opened many new attack vectors on the Linux kernel. However, I believe that currently the situation is much better, esp. after syzkaller and individual researchers reported and fixed many bugs in this area.

</comment></comment></comment></comment><comment><USER13> This seems to be almost exactly like systemd-nspawn other than the ability to write seccomp policies in kafel.

Are there any other notable differences?

<comment><USER8> I haven't been looking at systemd-nspawn for some time, but judging from its man page:

\- ability to use config files (in nsjail in protobuf format)

\- 3 operational modes: one of them allows to listen on a TCP port and run processes on-demand (inetd-style)

\- support for cgroups (pid and mem limiting), here rlimits are not enough

\- more expressive seccomp-bpf rules

<comment><USER13> > ability to use config files

systemd-nspawn supports ".nspawn" files (see --settings=true mode)

> socket activation

systemd can start up an nspawn thing in reaction to a systemd socket- activation request I think?

> cgroups

I guess for that you'd use 'systemd-run --scope -p MemoryLimit=10M -p CPUShares=100 -- systemd-nspawn ...'

> more expressive seccomp-bpf rules

Absolutely!

</comment></comment></comment><comment><USER14> I've been using nsjail in production with good success lately. It's a solid tool.

Thank you authors! Really appreciate your work on this project.

</comment><comment><USER15> I have become conditioned by seeing so many Javascript frameworks reach the front page over the years that I parsed this as 'JsNail' on first glance.</comment>


Ask HN: I'm based in UK but want to bill US customers. Any recommended services? - <AUTHOR>

I've looked into things like Stripe, which seems to be quite highly regarded, but unless I have a US precense it is hard for me (based in UK) to set that up.<p>Also looked at braintreepayments.com, they recently are accepting UK/EU. Anyone got any recommendations? <comment><USER2> Do you have a merchant account? You can charge anyone with a credit or debit card, and with a payment gateway you can automatically bill.

</comment><comment><USER3> I've used Google's Merchant service to bill US customers and it worked very nicely for me.</comment>