Ask HN: Which OS decision(OpensourceXproprietary) is conceptually more secure? - <AUTHOR>

Which OS decision is conceptually more secure Property based OS (MAC OS X) or Open Source OS(BSD, Linux)
Yes, I know we might find the exact answer, but I just want to hear your opinion on this unanswerable question. Also, you can denote exact OS kernel or arch. as an answer if you have rational reasons <comment><USER2> I think your question is too broad because it's too easy to confuse the different aspects of proprietary, free, commercial, source available, no cost, support contract, and volunteer support.

Why not narrow it down?

Which do you think is more secure, the open source Darwin operating system or the proprietary Mac OS X?

</comment><comment><USER3> No doubt, open source ones are more secure. Esp. For simple end users like us, it is at least as secure as we can see. Others are probably full of backdoors which are embedded by NSA.

<comment><USER2> I think you are making the mistake of assuming that proprietary OSes are never available in source code form.

I learned operating systems from MINIX. Nearly all of the source code was published in the back of the text book, and we had the kernel source code in order to modify and experiment with the OS.

However, before April 2000 MINIX was neither free software nor open source.

I think it's fair to say that this non-open source/proprietary software was not and could not be full of NSA backdoors.

Similarly, the original AT&T Unix distributions were also in source code form, even though they were also proprietary. It's very hard (but not impossible!) to hide backdoors in any software when you have the source code and the time to review it in depth.</comment></comment>


How my life was changed when I began caring about the people I did not hire - <AUTHOR> http://brookeallen.com/pages/archives/1234 <comment><USER4> Hi, this is Brooke, the original hiring manager. I'm new to HN so please excuse me if I violate protocol.

I agree, life is about treating people well. However, although I find hiring is probably the single most satisfying thing I did on my job, it was very hard emotionally because in the case of nearly everyone I don't' hire it is because they say "NO" to me, and boy, rejection hurts. But at least I have a job and my candidates usually don't.

More later but first…

If my site is unresponsive there is this on slideshare: [http://www.slideshare.net/BrookeAllen1/brooke-allen-has-a- be...](http://www.slideshare.net/BrookeAllen1/brooke-allen-has-a-better-way- of-hiring) I've generalized my approach to hiring all sorts and describe it here: [http://qz.com/88168/how-to-hire-good-people-instead-of- nice-...](http://qz.com/88168/how-to-hire-good-people-instead-of-nice-people/) …

When I'm lucky enough to talk to programmers I'll describe it this way...

I don't want to be stuck in Von Neumann's bottleneck so rather than me processing candidates in series with the question "Who do I want to hire" I take an OO approach and send a different question, "Who wants to work for me?" to my candidates so they can work on it in parallel.

Since hiring is an elimination process I let them eliminate me in the first rounds. I don't say "no" but I have to take a lot of it, which can be hard on the ego, particularly if I judge people too early and start to want one person over another. Desire is at the root of suffering. (Any fans of the move The Tao of Steve? Formula for getting the girl: 1) Be desireless. 2) Be excellent in her presence, 3) Let her desire you.)

I try to be the most flawed (e.g. honest) but-striving-to-be-excellent person I can be in front of my candidates and hope they will be the same for me (and magically they are). If we're not going to be who we are before we start working together who do we plan on being afterward?

Because eliminating candidates is the name of the game, I concentrate on the negatives and that way there are only positive surprised later. Arguably many of my "best" candidates might eliminate themselves, but I'm not looking for the best – I can never afford them anyway – I am looking for the most appropriate for my budget, which I state early on and is almost never subject to negotiation. You cannot increases your desirability to offer to work for less, and if you are worth more than I can afford than I'm sorry, but I cannot afford you.

I want what I call hidden talent; those good at doing a job but bad at getting one. After all, the last thing I want you to be good at on my job is getting the next one. I'll help you find a better job before I hire you because afterward we've got to hunker down and get some friggin' work done.

Because I form an intentional temporary community of my candidates, and task them with something hard but meaningful that benefits them (like learning a new skill and/or helping each other find work) then by the time I say "yes" to someone everyone else agrees with the decision. In fact, in 10 years only once did a person tell me he thought I had made a mistake by not hiring him and the other candidates were so outraged they jumped all over him and one – who happened to be a lawyer – offered to defend me pro bono if he tried any funny business.

I never heard from him again but it is my great pleasure to say he is an exception in that regard and I count a few of the people I haven't hired among my friends. This is a wonderful side-benefit because as I get older it is harder to make new friends, and it is certainly unwise to treat employees as friends as some do.

I seldom tell individual candidates what they did wrong, not because I am shy, but because it can be hard to take and I'm fairly tactless. However, I will offer a class on how to find work in which I anonymize specifics enough so as to benefit those who can identify themselves. Also, most people don't do anything seriously wrong other than be unqualified or unlucky; no shame in that.

More later, if you're interested.

After 30 years I've retired from the capital markets and they will do fine without me, but the markets for human capital are severely broken. Because I'm not ready to die, stop working, or give up on having a life's purpose, if you would like me to help you crack this nut then please do not hesitate in contacting me.

<comment><USER5> _> hidden talent; those good at doing a job but bad at getting one_

I really like this. If you're bad at getting a (good) job then employers safely assume you would also be bad at the job - it's too risky otherwise. But often that isn't the case, because there's a lot of "hidden talent".

What can we do to give those people a fair chance? We need effective ways to discover hidden talent. The process you described worked for you, but it doesn't seem practical. Too time consuming for both the employer and job seekers, and not rewarding enough for those who don't get a job out of it.

<comment><USER6> Are there ways to help those talents get together and start their own companies? Otherwise, they may go to interviews and keep getting rejected.

<comment><USER7> Do you think those people who are not good at selling themselves are going to be good at convincing people to buy their stuff?

<comment><USER8> That depends on why they're bad at selling themselves. For instance, if they get ridiculously self-conscious when the conversational focus is on _them_ , that shouldn't get in the way of selling something else.

<comment><USER9> Hi, I'm Noah and I head BD for Better Work World, the organization I have started with Brooke to help firms hire the way he did. As for the above comment, this is true but the larger point is that, if the job isn't explicitly a sales position or doesn't require gaining internal agreement (like, say, many managerial roles)`one's ability to sell one's self in an interview is somewhat irrelevant, wouldn't you agree? Think about it: if you are a coder and happen to have several social anxiety issues, you would probably be an awful interview. But who cares? The market for coders is so hot it seems that has been largely accepted, albeit implicitly, but for less hot positions, not so much. We believe candidates win and hiring managers win when you focus on getting people to DO the work as opposed to talk about doing the work. When Brooke hired this way he found people he would have never hired through reviewing resumes, so thats a win for both of them, and those whom he did not hire-- many of whom had been unemployed-- would usually quickly find jobs elsewhere because they were given the opportunity to do relevant work, network, etc. To me, that beats the standard, "what's your biggest weakness?" line of questioning any day of the week.

</comment></comment></comment></comment></comment></comment><comment><USER10> I've done a LOT of interviewing, recruiting and ultimately a lot of saying "no" to people.

Over the years I've landed on a series of personal rules on how to do just that.

1\. Always explain rationale around the No, to help them improve 2\. Always let people down gently reinforcing positive notions as well, you never know what state of mind they are in. 3\. Always respond to requests for more information

This takes me a lot of time in my professional life, but it's making me a happier person. Ultimately, it's people's lives you're dealing with. You don't owe anyone anything, but life is about treating people well.

<comment><USER11> Then there is the perspective from having heard "no":

1\. Never believe anyone's rationale regarding their "no". They acted on instinct, and made up a clever story to afterward to convince themselves it was a rational decision. Or worse: it was some prejudice that they are consciously covering up. Or perhaps some internal reasons that they don't want to discuss with outsiders like sudden news that affects all hiring activity (but this news can't be made public yet: even the fact that there is such news).

2\. Don't take it personally.

3\. Never press people for more information: waste of time.

<comment><USER12> I don't do the actual hiring, but sit in in one of the two interviews, and as a team we carefully discuss each candidate. We've got a good team, the work environment & people are great, hiring process is solid enough. And we all agree that, _almost_ without exception, we can tell within about thirty seconds of meeting them whether someone is likely to be hired. I _assume_ this is overwhelmingly common? Bar sending a polite rejection letter, we would often prefer not to explain the actual whys[1], as often they are personal. Kudos to the OP (and yeah, it would make you feel good), but I'd tend to agree with you on this.

[1] that being said we always, always try to give some constructive feedback if asked.

<comment><USER13> I, seriously, don't understand how this works, unless your candidates appearance and accent are your main tools for judging a candidate. I would prefer to think that's not the case. If you were teaching a new member of the team to make such a decision, what would you point to?

What's more important, is I don't understand how anyone could possibly improve their 30 second impression.

I guess it could be that you believe this to be the case, and are remembering wrong. Why don't you note this down after 30 seconds, and then check it only after you make a decision to see if you were correct?

<comment><USER12> Yes, I admit there is an element of hyperbole (for 30 seconds probably read 30seconds - 5 minutes depending, and that alters if a candidate [ie for a junior position] is nervous and it takes time to get them to relax somewhat).

Appearance is important, and I've never been in an interview situation where it wasn't? Unless you're insinuating choice based on ethinicity (more aimed at _pmf_'s response to your comment). Which is completely irrelevant, as are accent/sex/other discriminatory factors that make zero difference to how someone is likely to work within a team.

As I've said in other comments, there is a serious element of external preselection based on geography and company sector, there's nothing particularly underhand going on.

<comment><USER14> > Which is completely irrelevant, as are accent/sex/other discriminatory > factors that make zero difference to how someone is likely to work within a > team.

This is just plain ignorant. Every single place I have worked has had its share of everyday sexism and racism, and that includes how current employees act in hiring interviews. You claim to not notice these things, but what you are saying is that you don't consider those things valid differences that may affect how someone perceives your team or work environment. How can you ever confront issues in your workplace by shoving your head in the sand?

</comment></comment></comment></comment></comment></comment><comment><USER15> The first time I got a front page link to my site on HN, it did this exact same thing, which prompted me to move away from Wordpress. Static HTML ever since.

But to comment on the article, I think this is a fantastic idea. I do wonder though how he found so many enthusiastic people. Maybe it's just a new era, but I have a hard time finding people who even want to do a 1 hour coding challenge. He got these folks who were willing to learn something, and build and spend DAYS on it? It's awesome but it seems unlikely these days.

Taking that kind of time to choose the right person, then helping the other people network with other APL folks... that just spreads good vibes all around. I would like to see the "care more" trend spread in our industry. Even now with a programmer shortage companies are still unicorn hunting and making people jump through stupid hoops for jobs.

<comment><USER16> My Wordpress blog used to go down because of HN. I fixed that as follows.

1\. Use the Wordpress supercache plugin.

2\. Put Apache behind Nginx, and limit the number of Apache processes to ~6. This way you're effectively using Apache as a "PHP app server", simulating an architecture similar to Passenger/Unicorn. Nginx acts only as a buffering reverse proxy, shielding Apache from slow clients.

Why this instead of running Wordpress/PHP through Nginx using php-fpm? It's because Apache is just easier: mod_rewrite rules work automatically, etc.

<comment><USER17> This is first time I've seen the words "Apache is just easier" in that arrangement. I think php-fpm is significantly easier to set up than Apache and expect it to be more performant with less resources.

<comment><USER18> This probably depends more on experience, and which OS/platform you're using; although I don't do it a lot, I've configured Apache servers several dozen times, whereas I've only done nginx a couple of times, so it is 'easier' for me.

Also, on ubuntu (and centos, but haven't used it in a while), it is something like 'apt-get install apache-mod-php' and everything is there :)

</comment></comment></comment></comment><comment><USER19> This story reminds me of how broken software engineer interviewing is. Imagine if a company decided to hire software engineers by giving them five 6-sided dice. Then they have to come to the company building and roll each dice once every hour. And during that hour they have to dance and sing in front of someone while being recorded. If they roll all 6 on all 5 dice, their dancing and singing will be judged by the committee! And if the committee likes their performance they might get the job! The acceptance rate is 0.01%, the company is so elite. And this company is also complaining about a software engineer shortage. They wish they could find more good engineers!

It's pretty obvious which company (or group of companies) I'm referring to. The interviewing process of these companies has done great harm to the software industry. And now they're trying to do further harm by using it as an excuse to get cheap foreign labor to reduce salaries.

<comment><USER20> Palantir?

<comment><USER21> I believe he or she is talking about Google.

<comment><USER22> Google's acceptance rate is well above .01%, just using basic reasoning. Google employs tens of thousands of engineers, which means they would have had to reject hundreds of millions of candidates for the role of software engineer.

<comment><USER23> You're hired!

</comment></comment></comment></comment></comment><comment><USER24> I wonder how much of this kind of thinking can be traced back to a persistent startup-culture problem: the delusion that the people who work for you are, or even _should be_ , your friends.

If that's the lens you're looking at candidates through -- as people auditioning to be your friend -- of _course_ you'd feel you're obligated to help them through their job search! That's what friends do for each other.

But the people who work for you -- and even more so, the people who have only _applied_ to work for you -- are _not your friends._ You can (and should!) be friendly with them, of course; but you can't have a real, true friendship with them, because you have power over their lives that they don't have over yours.

Moreover, if you try to just ignore that power differential and relate to your employees like they're your old dorm buddies, all you'll find is that the power differential poisons the relationship. They'll constantly be second- guessing their own reactions to you, out of fear of negative job consequences. You'll constantly be second-guessing _your_ own reactions to _them_ , out of fear of appearing to play favorites. And they'll all be second-guessing _each others '_ reactions to _you,_ out of fear of someone brown-nosing their way past them on the career ladder.

It's the same reason why it's always a bad idea to date someone who reports to you -- you can never have the kind of relationship with them you have with someone outside the hierarchy you sit at the top of. Suspicion and jealousy and gamesmanship taint it from the moment it begins.

The solution to all these problems is to learn, understand, and internalize the distinction between _colleagues_ and _friends_ \-- two groups of people you owe very different things to -- and then act accordingly.

</comment><comment><USER25> Google cache since site is down: [http://webcache.googleusercontent.com/search?q=cache:bfmrmRK...](http://webcache.googleusercontent.com/search?q=cache:bfmrmRKzUdEJ:www.noshortageofwork.com/pages/4063+&cd=1&hl=en&ct=clnk&gl=us)

<comment><USER26> Pastebin for posterity when case Google Cache expires:

[http://pastebin.com/raw.php?i=QtePMR26](http://pastebin.com/raw.php?i=QtePMR26)

</comment></comment><comment><USER4> Hi, this is Brooke, author of the original story.

Wow, other than the grief I'm going to get from my ISP I'm so glad to see all this and when I get a chance over the next few days I'd like to add more.

Some quickies: I've generalized this approach and talk about it in a Quartz article: [http://qz.com/88168/how-to-hire-good-people-instead-of- nice-...](http://qz.com/88168/how-to-hire-good-people-instead-of-nice-people/)

<comment><USER27> You might want to look into Cloudflare to help protect your site from the HN/Digg effect. Free CDN FTW. Also, great story!

</comment></comment><comment><USER28> When you hire for a _person_ , you find that personality traits are much more important than what an applicant has done in the past, including passion, drive, etc.

When you hire to fill a position, all this goes out the window the applicant goes into the hiring lottery pool to maybe get an interview, and then the traditional "You could totally goog this IRL, but I'm going to hire you based off your memory" type of hiring.

<comment><USER26> I find that > 90% of interviews to be the latter, unfortunately. The ones where I got the job were the former! I am stronger at concepts than memory.

<comment><USER29> The worst is when you have to go through one of those interviews with some smug hoser across from you whose face is contorted into a rictus grin because you couldn't recall, immediately from memory, some obscure Junior Year Computer Science thing. It's just amazing how bad the hiring situation is - <USER2> makes me a lot less likely to look around because I just don't want to go through that.

<comment><USER30> Yet the number of interviewees with a CS degree that can't even _explain_ a basic algorithm, like traversing linked lists or binary search, is staggering.

<comment><USER31> It's amazing how the brain can totally blank in stressful situations.

<comment><USER30> Eh I doubt that explains it. In my experience, the response is shock. Not "oh hmm well, lemme think". It's " I've never written that code since school! That's a terrible thing to ask! Why would I ever write that? "

Also, for trivial algorithms and data structures, mind blanking is a potentially bad sign. Like, if you cannot explain the idea of garbage collection (not necessarily implementation details), then I gotta question your understanding of your environment.

<comment><USER32> I am reasonably experienced programmer who has delivered numerous web applications and websites. I could not explain to you how a linked list or binary tree worked - although I am sure I could look them up on google and understand the concepts given 30 minutes.

<comment><USER33> "Experienced programmers" who don't understand linked lists and binary trees without looking them up are strong no hires anywhere I have worked in the last three decades. Please stop writing software until this isn't a problem.

* edit: please stop asking people to pay you to write software. Keep writing software on your own until such elementary ideas such as linked lists and binary trees are core to your understanding, then apply again.

<comment><USER34> I have yet to encounter a situation in my career that called for a binary tree. I use general trees and graphs all the time, but never any of the specialized forms.

Maybe the problems your companies have worked on did. That's fine. Don't go telling people to "stop asking people to pay you to write software" just because they don't know how to use or write a binary tree, though.

I agree with you that I wouldn't hire someone who doesn't understand linked lists, but I still think your statement is too harsh for that situation as well.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> To generalize the point a bit:

I don't think enough companies are doing enough to help the ecosystem.

Like foresters chopping down the Amazon, or fishers taking the last fish from the ocean, they want to harvest good talent and then stick them in jobs where they can be a cog in the wheel it is hard to grow. They expect other companies to have given them the training or perfect relevant experience.

And then we hear complaints there there is a shortage of hackers etc.!

<comment><USER35> I completely agree. I would include supporting open source projects as another way to practice sustainable development. Many kinds of personalities wilt in corporate environments that could work (for relatively cheap wages) on open source projects that benefit everyone.

<comment><USER26> I read Michael Church's blog and from reading that I am convinced that we are our own worst enemy. We spend our spare time writing open source code, which then businesses can profit from without having to pay any of their own staff.

I think companies should allow staff to spend some time on open source. It could even benefit the company by having their name associated with it, making it seem like a cool place to work, and having CV's coming in the 'we're hiring' page begging for an interview instead of expensive agencies. But there you go.

<comment><USER36> I think it's somewhat of a misconception that most OSS is written for free in professional programmers' spare time. For small projects yes, but corporations aren't using their code anyway. OSS projects that are prominent enough to achieve corporate adoption, often have a staff of core maintainers that are employed by a company that makes money selling support for that OSS software. Why? Because corporations are risk averse and using OSS without a support service contract is a risk they won't take. Unless they are a software company capable of directly supporting the OSS themselves, in which case you also get devs contributing to OSS projects on company time.

I don't have statistics for this, but I can easily cite a lot of examples.

On the other hand, there are also a lot of contributors that do it for free but they are not doing it purely out of the goodness of their own heart either. A lot of them are doing it either because they are heavy users of the project and/or to practice and build up their portfolio (read: Github profile) to help them get a job.

<comment><USER37> Not always. TrueCrypt and OpenSSL comes to mind first. Sure, OpenSSL is more supported now, but it happened only after Heartbleed panic, when everyone realised how dependant they are on few overworked and underpaid programmers. Except several well known OSS projects, most others get only peanut money from donations.

<comment><USER36> These are sort of the exception that proves the rule, though. Corporations don't want to rely on poorly supported OSS projects, they prefer to pay for support so they can hold someone accountable for fixing it when it breaks. OpenSSL was a bit of a blind spot in this regard. I think corporations just didn't realize they were depending on it and/or how much of a risk factor it was, they learned that the hard way.

</comment></comment></comment></comment></comment></comment><comment><USER38> So unless I'm reading the cached text wrongly 38 people read the given manual and answered programming questions based on it. They then met informally. Lets say they burnt a day on this.

27 of those people then suggested being taught how to program in APL (after building a classroom). I'm assuming anyone who didnt want to attend got cut. 3 additional days spent.

They were then given 3 weeks to solve some difficult problems. Estimating they spent 4 days solving those problems.

They then re-met and were interviewed. Another day spent.

So to get to the end a candidate had to spend best part of two work weeks doing nothing but learning and programming an obscure language. No time for interviewing elsewhere, earning a wage, or attending college classes.

I would really hope he cared about the majority of the candidates who spent so much of their own time and money to be rejected with nothing to show for it. Most companies would have interviewed a couple of times, given a few hours of programming/aptitude testing and made a decision as to whether to hire the person (and teach them the job while paying them a fair wage).

Feel free to vote down if I'm getting this all wrong or an being overly cynical.

<comment><USER39> I'd like to offer an alternative perspective. The author was both willing to hire people with no experience, and provided free training to candidates. I realize that APL isn't a skill in incredibly high demand, but I think the author may have helped these candidates out in the long term. The ones with the most aptitude for programming were able to discover that aptitude (and "a number" of them were hired because of their investment), and the less apt candidates got a little bit of training and possibly an indication that if they are interested in programming they would have to accept putting in a bit more effort than the more apt candidates.

<comment><USER40> Don't confuse training with education.

Free job training is not equivalent to free education. The latter provides skills and knowledge for the future benefit of the student. That determination of future benefit is often made by the student. The former also provides skills and knowledge, but it is for the future benefit of the employer, and employer-directed. That represents a foregone opportunity. Any trainee could have spent the same time acquiring free education, traded it working in a job that does not require that marginal additional skill, or even wasted that time on leisure activity.

Trainees should always be paid. In this case, they were paid with in-kind services upon conclusion of the training program. To do less might have earned the author a reputation for unethical behavior.

Many companies seeking to hire within the software industry do not recognize the opportunity costs imposed by their hiring procedures. If you require candidates to waste an entire day or more on your interview process, yes, you do owe them something for their time. It need not be settled in cash, but if not, honest feedback on the results of the interview is the bare minimum acceptable payment. The interviewees are expecting their lost time to be an investment, not just a gamble.

</comment></comment></comment><comment><USER41> This hiring process is great, but requires lots of time, for the applicants and especially for the hiring manager - I suspect the author was targeting unemployed people, so they would have time for this long application (he put his job advert on the New York Times). To be honest, that is what surprised me the most in this article: that someone who runs a statistical arbitrage desk has the time for all of this.

I wonder if companies could collaborate to create this hiring process. It would save hiring manager's time, applicants' time since one application will count for different jobs, and then a system could be set for candidates to rank their employees, then the candidate who performs the best get his first wish, the second candidate gets is first wish if there is still room, otherwise he gets his second wish, and so on - a similar system is being used in France for students to chose in which universities they want to go after competitive exam entrance, basically lots of universities pool exams together.

On one hand it would scale hiring process, on the other hand it's not flexible and offers have to be transparent (it's currently not the case but maybe that would be a good thing), and it would hurt the pride of companies who are ranked in the last position.

In the case of the article, I am sure someone who is able to solve in a language he recently learn the non trivial software that are mentioned will be able to land a job at some point. It was written in 2004, maybe Github, Stackoverflow and Open Source in general are now contributing to that selection.

</comment><comment><USER42> Money quote : _" I started No Shortage of Work to encourage my unemployed friends to re-frame their status not as a disaster but as an opportunity to explore new vistas."_

This is something which people often forget, is that learning needs to happen life long, it isn't a 'did college, check that box.' kind of thing, its about always learning. Its the first thing I check for when I look at people to hire.

</comment><comment><USER4> Hey, other then the grief I'm going to get from my ISP this is great that you're interested.

While we figure out how to get my site working again, I wrote this in quartz: [http://qz.com/88168/how-to-hire-good-people-instead-of- nice-...](http://qz.com/88168/how-to-hire-good-people-instead-of-nice-people/)

and this for Science Magazine: [http://sciencecareers.sciencemag.org/career_magazine/previou...](http://sciencecareers.sciencemag.org/career_magazine/previous_issues/articles/2007_11_16/caredit.a0700163)

And there is this Slideshare: [http://www.slideshare.net/BrookeAllen1/brooke- allen-has-a-be...](http://www.slideshare.net/BrookeAllen1/brooke-allen-has-a- better-way-of-hiring)

</comment><comment><USER43> How bad can it get? Several years ago I had a Russian team lead at a software company who ate code for breakfast (clearly the top guy amongst over 100 coders) and had excellent leadership qualities.

Later, when the financial crisis hit he was out of work and I found out that he was really bad at interviews. Ever since I've wondered if I was hiring would I be able the spot the diamond in the rough where evidently, very few companies/people can. I'm still not sure.

</comment><comment><USER44> I sometimes consult to clients on improving their hiring process. Candidate experience is now a topic that at least some companies consider.

This isn't your typical candidate experience - applying for a vague job ad, being asked to answer 6 puzzle questions, invite to an open house, two days of free training and then left alone for three weeks, followed by a vote by the tribe to see who will get the job.

It's definitely a plus that many of the students were hired elsewhere, but this is likely a method that would only appeal to the unemployed. I hear quite a bit of negative feelings towards companies that ask for extensive amounts of time commitment during the hiring process, and this is probably the highest level I remember.

If most companies asked candidates to go through this process, I expect they would want (and feel entitled to) some explanation at the end of the process.

<comment><USER45> Good points here. Some of those who left the process in the beginning may have simply had better things to spend the next month on, not because they were inferior candidates. I like the tone of the article in general, but it does smack of a certain entitlement on the employer's part whereby they feel justified in extracting many thousands of dollars of free work from unemployed job seekers. Despite the admirable intentions, the caveat that some of those who didn't receive a job immediately were later hired elsewhere is only meager consolation, as I'm sure there were significant contributors who were not proportionally compensated.

<comment><USER46> >extracting many thousands of dollars of free work from unemployed job seekers I didn't get the impression that they provided any value to the person hiring them. To me it just seems like they got some interesting, hopefully fun training in APL over a couple weeks. If I was unemployed and had the spare time (Like I was a couple months ago) that sounds like something I would have loved to do.

</comment></comment></comment><comment><USER47> In the US are there legal reasons why employers generally are tight-lipped about why a candidate didn't get hired?

<comment><USER48> I've always thought so, and I figure it is a case of our sue-happy culture and a cover your ass tactic "anything you say can and will be used against you" kind of fear. I'd love to have reached out to some applicants in the past to offer help, but what if they don't want any?

<comment><USER49> It would be nice if, at the start of the application process, companies could ask you if you would like to agree not to sue them in exchange for open, honest feedback, e.g. notes from your interviewers.

Sometimes its pretty clear if you are not a good match, but sometimes its really not, and it seems like it would be best for both parties if certain kind of feedback could be provided, e.g. you were close, please consider applying in a year or two with some more experience, or we have decided not to hire anybody due to a later hiring freeze, but otherwise we would hire you - or, you are a unlikely to ever work in this industry, don't waste anybody's time with further applications (maybe some suggestions for better fits).

In general, more information leads to more efficient markets benefits all participants.

<comment><USER50> I believe one of your legal rights is you can't be compelled to sign away your legal rights in exchange for something like a chance at employment.

<comment><USER49> The idea would be that its optional, and the company would still treat candidates choosing either optional equally during the hiring process - <USER3> would not be a condition of applying.

So, you aren't signing away your legal rights in exchange for a chance at the job, you get that either way. You are agreeing not to exercise some legal rights in exchange for feedback, not in exchange for your application to be considered.

<comment><USER51> If you're agreeing not to sue, then the company can use any criteria they like to hire or not hire you and there are zero consequences.

Imagine you check the box, you don't get the job, and your feedback turns out to be "You're a man and we don't like to hire men." You have no recourse because you agreed not to sue.

You can argue that that's obviously illegal hiring criteria and you should be able to sue anyway, but then you're back to square one.

</comment></comment></comment></comment></comment></comment><comment><USER52> I have mixed feelings about this.

It's easy to see what's to love: an open, honest, and collaborative hiring process with a boss willing to train employees. Awesome!

But he also got about 30 people to spend four weeks building trading software for him. Collectively that's over two years of uncompensated work, the results of which the hiring manager may use for free. And from the perspective of the applicant, how many applications could they complete in a year if all were so time intensive? 12? 24? I suspect many top applicants would avoid this process entirely.

<comment><USER53> From a worst case cynical viewpoint, he got free labor and those people got free training. It wasn't like he chained them to a desk and then made them get jobs in PHP. Best case, it was a mutually beneficial relationship entered into rationally and with eyes wide open. Top applicants might avoid it but people trying to break in and show what they can do might jump at the chance.

</comment></comment><comment><USER54> Google Cache mirror: [http://webcache.googleusercontent.com/search?q=cache:1tQlU00...](http://webcache.googleusercontent.com/search?q=cache:1tQlU00Ks7MJ:brookeallen.com/pages/archives/1234+&cd=1&hl=en&ct=clnk&gl=ca)

</comment><comment><USER55> This is quite similar to how we hire Ruby on Rails developers. We organise two-weeks long Bootcamp where we train people in Rails. At the end we offer some of them to join us as junior developers, with further training during next year. Those who are not hired still win—they receive two weeks of training which helps them find jobs elsewhere. We've had some fantastic hires this way over the past two years.

This article made my think that maybe we can do better and provide more assistance to those we do not hire after Bootcamp.

More details about our Bootcamps are available at [http://pilot.co/bootcamp](http://pilot.co/bootcamp).

</comment><comment><USER56>
        So, here is my answer to the question, "What do we owe the people who we do not hire?"

        - Information on where they stand.
        - An explanation of what they are doing wrong.
        - Help improving.

Things you will never get from companies like Google.

</comment><comment><USER57> The best example I've seen for putting together a team comes from my high school football team. Instead of tryouts, they let anyone play who wants to play. The best players excel from day one, but the crappy players quit after a few days. The coach never says to a player "we've decided you aren't good enough, so you're off the team". It was each players decision that they came to themselves to leave the team.

The guy in the article pretty takes the same approach. I've always felt the best way to interview engineers is to go over installing the company's development environment on their machine. In other words, there is no evaluation, just expectation of results.

</comment><comment><USER58> "So, here is my answer to the question, "What do we owe the people who we do not hire?"

        1. Information on where they stand.
        2. An explanation of what they are doing wrong.
        3. Help improving."

Nope! You don't owe them those things. Good for the author that they tried it and it worked out, but it's not a general rule.

Everything works smoother in lots of different parts of life if all parties understand the concept of a Clean No. Not "You can say No but then you still owe me such and such". Just "No." Anything beyond that is a gift.

<comment><USER59> Lets talk about a simple example. You apply for a visa to X country for a special occasion (eg; brothers wedding, graduation ceremony et.al). Two weeks later, you get a response saying "No", just no.

Will you be satisfied that you never got any feedback to why it was refused, what you did wrong and what to do to fix it?

Feedback, be it good or bad is crucial. I, myself appreciate this feedback, especially in this scenario the author is talking about. How am I supposed to improve my self when I don't even know what I am doing wrong?

<comment><USER58> Feedback is extremely important. So important, in fact, that you shouldn't rely on _deeply_ compromised sources for it.

People who have just rejected you will never be reliable sources for feedback (on average). That's what friends, confidants, and inside sources are for.

</comment></comment></comment><comment><USER60> FutureAdvisor's in-house recruiter here.

I recently ran a hiring event in San Francisco with Brooke called Staffup Weekend. Brooke is one of the smartest, hardest-working and most generous people I know. I read the post linked to above last fall, and worked with him to bring jobseekers together to work on meaningful projects. The event was called Staffup Weekend, and it was held in the Chron building on Mission and 5th.

Our hypothesis was: The only thing that correlates with performance is performance. Everything else -- degrees, pedigrees, buzzwords, interview skills -- are a waste of time. About 20 people worked through the weekend to create various apps. They made wonderful things: one was a Chrome extension that gives you the emails of the founders of the company web pages you visit. Another was a LinkedIn 2.0 for people who wanted to feature their work and themselves. We made 8 interview offers and one hire from the weekend, and I think everyone involved came away feeling like it was worth it. Write me if you're curious to learn more: email@example.com

</comment><comment><USER61> I interviewed an engineer today. Probably a lot of companies would not hire him. He was not that great. I said "Yes" because I noticed a passion and a huge desire to learn and grow. We'll see if that was a mistake or not.

</comment><comment><USER62> I attended a bootcamp at ArsDigita on building database backed web applications back in 1999. I don't recall now if it was two weeks or three, but the things I learned in that short time have been useful in almost every job I've had since. Just knowing my way around Oracle an PL/SQL landed me a position at a telecom. The bootcamp was free, and at the end of the bootcamp after a code review I was offered an interview. I declined because I didn't want to live in Boston. I realize that Philips motives weren't entirely altruistic but I am sincerely thankful that he took this approach to staffing up.

</comment><comment><USER63>
        Fatal error: Out of memory (allocated 9961472) (tried to allocate 19456 bytes) in /home/quest15/public_html/brookeallen.com/pages/wp-includes/taxonomy.php on line 959

</comment><comment><USER64> The real solution here is not to interview people, but to discover people OUTSIDE of a hiring scenario, and recruit them after you've determined they would be a great fit (inverting the game). It's just unfortunate that it is much more effort to invest as the employer, but it is essentially the best way for everybody involved.

</comment><comment> alishan-l As a job seeker having recently completed a web dev bootcamp (with no prior experience), how might I go about getting my first tech job? Or, taking a step back, my first interview? I find it frustrating that entry-level positions seek people with years of experience.

<comment><USER65> One thing to keep in mind is that "entry-level" means the most junior position with that company, not "entry-level" into the workforce at large. I found this equally frustrating in non-technical jobs after I graduated college (with a liberal arts degree). It's a rather encumbered naming convention.

</comment></comment><comment><USER66> Google cache of this page:

[http://webcache.googleusercontent.com/search?q=cache:1tQlU00...](http://webcache.googleusercontent.com/search?q=cache:1tQlU00Ks7MJ:brookeallen.com/pages/archives/1234+&cd=1&hl=en&ct=clnk&gl=us)

</comment><comment><USER67> This sounds like the job search from hell. Let's break down this trainwreck:

1\. The guy posts a vauge help-wanted ad that implies no experience is required. Then he's surprised that 300 people applied and none had relevant experience.

2\. He asks applicants to read a 500 page manual, then solve some programming puzzles. With no pay. As if the applicants have nothing better to do.

In the rest of the story, the guy does a nice thing for the remaining applicants. But why does he ask candidates to jump through so many hoops for this job, especially when, as he states in the ad, experience is not required. Not every unemployed person has the time to read a manual, waste time solving puzzles, or attending a class with no guarantee of employment. Some of them _really need jobs_. Some of them have bills to pay. Some of them have other opportunities, and can't afford to put their life on hold while you make up your mind.

</comment><comment><USER68> Or "How my life improved once I started making friends"

</comment><comment><USER69> "Resource Limit Is Reached"

this is how

</comment><comment><USER70> brilliant!</comment>


Implementing a fast interpreter without resorting to assembly - <AUTHOR> http://www.emulators.com/docs/nx25_nostradamus.htm <comment><USER2> Brilliant. Fascinating how he slides from switch-dispatching to function pointers, deals with the problems there, then does that thing where the function pointer returns the next function pointer. But that's just skimming the surface of the brilliance there. The intricacies of his observations have a sparkling beauty.

<comment><USER3> I've worked with him. He's a smart guy. :-)

</comment></comment><comment><USER4> > and thus debunk one of the greatest virtual machine myths of all - the blind > faith in the use of jitting as a performance accelerator.

It's not blind faith, it's demonstrated in pretty much every situation where an interpreter and a JIT are both available for the same language. All of the fastest VMs out there today (V8, LuaJIT, JVM, etc.) are based on a JIT.

> The performance level made possible by the Nostradamus Distributor also > means that [interpreter-based] Bochs could purely interpreted pretty much > match the performance of [JIT-based] QEMU, although I admit that is still > left to actually implement and try out.

This sounds like blind faith to me.

<comment><USER5> Just for the record, while I agree at least in principle regarding your assessment of interpreters vs. JIT compilers, the situation seems to be far from clear though, and I think the last word is not yet spoken on that topic.

As far as I am concerned, most of the benchmark suites out there give an unfair advantage to JIT compilers. For example, all numeric JavaScript and Python benchmarks can be heavily optimized by JIT compilers (essentially removing all of their interpreters' weaknesses: (un-)boxing, dynamic typing, and in the case of Python, reference counting; plus removing the interpreter overhead [i.e., instruction dispatching]). Many of the benchmarks are numerical in nature, too, even if the actual workload is usually non- numerical. So it might very well be that your actual workload does not use any of the fancy numerical operations that a JIT can optimize heavily. In such a case, the additional memory consumption of the code caches and the additional memory requirements of a generational garbage collector may in fact not give you any practical speedups in comparison to a sophisticated interpreter using just reference counting (which is known to be very space efficient).

Aside of this unfair skewing of benchmarks towards numerical computations, there are other points to consider in the discussion of JIT vs. interpreters, such as energy consumption. Does a programming language implementation using a JIT subsystem require more or less memory than an interpreter? (I am positive that some companies have already measured this, but there are AFAIK no publications concerning this important question.)

Summing up, I think--as is so often the case in computer science--which of the two techniques give the best results depends heavily on a) what trade-offs you/your customers are willing to make [space vs. time] and b) the actual performance is of your workload [numerical vs. non-numerical].

<comment><USER5> EDIT: Of course, the question in the third paragraph should read:

Does a programming language implementation using a JIT subsystem require more or less _energy_ than an interpreter?

</comment></comment></comment><comment><USER5> I have just read the post and have to say that I would appreciate the post containing a more accurate description of the testing methodology. Some of the techniques described are known in interpreter optimization and his description of "threaded code" intepreter is actually not consistent with what it usually means (viz. threaded code interpreters have nothing to do with "threading" the decode for the successor instruction into the operation implementation of the current instruction, but just moving instruction decode and dispatch into the operation implementation.)

Aside of that, there have been papers detailing the software pipelining approach (cf. Hoogerbrugge et al.: "A code compression system based on pipelined interpreters", 1999), but I cannot for the love of god imagine that the loop shown in there is faster than a JIT compiler for a very simple reason: each of the interpreter operations is invoked via a function pointer, which means that the compiler emits an indirect branch instruction for implementing this. Now, these indirect branch instructions are _very_ costly, and a simple JIT compiler could just take the actual values (callee target addresses) of the input program and generate direct call instructions instead. (And I am not even talking about inlining the function bodies of the operation implementation.)

<comment><USER6> Indirect branch is not too costly when it is correctly predicted and due to proliferation of C++ code, modern CPUs are very good at predicting indirect branches when they mostly lead to same target.

</comment></comment><comment><USER7> I'm not sure I understand the attraction of writing a fast interpreter, as opposed to writing a JIT or ahead-of-time compiler. If you're going to the trouble of optimizing the hell out of your interpreter, yet compiling will always result in faster execution time, why not go directly from an easy, one- off slow implementation to writing a compiler, instead of spending your time optimizing the execution loop?

<comment><USER8> Writing an interpreter can be a lot simpler than coding an equivalent compiler. Suppose you have an old game you want to play that was written in hand crafted 8080 ASM. You can emulate an old CPU at reasonable speeds and get a complete working solution. But, if uses say self modifying code there really is no way to directly map 8080 to x86(64) instructions.

But, a more common case is it let's you debug systems. Even if you can't run an iPhone app in full speed on your desktop you can inspect what's going on in detain with an emulator in a way you can't really do with compiled code.

</comment></comment><comment><USER9> The content of the website is beyond awesome.

<http://www.emulators.com/docs/nx33_qemu_0125.htm> first caugth my eye.

then <http://www.emulators.com/docs/nx30_bochs245.htm>

</comment><comment><USER10> Too bad I'm coming late to the party, but those interested by this post might be interested by the test implementations that I made a few months ago to bench various design parameters of interpreters (bytecode size, gCC computed goto extension...) in high level (I.e boost::variant<>) C++. I don't have the numbers at hand but I remember it was very CPU dependant. You can try for yourself, it is only a few self contained small programs : [https://github.com/scientific-coder/Computer- Languages/tree/...](https://github.com/scientific-coder/Computer- Languages/tree/master/interpreting)</comment>


What 800 Nerds on a Cruise Ship Taught Me About Life, the Universe (2014) - <AUTHOR> http://www.wired.com/2014/12/nerd-cruise/

<comment><USER2> > Where the Sea Monkeys see community, I see epistemic closure. All the shared > references and common rhetorical tactics don't feel supportive to me—they > feel almost lazy, as if the triumph of the nerds means not having to meet > the normals halfway.

This really is the main problem with nerd/geek/gamer/etc "culture", it's actually very exclusionary to people and if you don't possess the right amount of shared knowledge, you're ostracized. Nerd "culture" is also uncritical of the objects of worship, watch what happens if someone criticizes a sacred cow like Firefly or Game of Thrones.

Critical of individuals and uncritical of art is exactly the opposite of what we should strive to be.

<comment><USER3> Yeah, for all the whole "haha look at all these normal people caring about their local sports teams"-type of memes in those circles, popular nerd culture is basically exactly the same sort of behavior.

There's extremely vile behavior in these circles, a sort of one-up-manship that ends up creating environments where things like Gamergate can prosper.

<comment><USER2> Exactly, it becomes a race to define the most narrow circle of who is "in" and who is "out" and since nerd identity is defined by consumption, it becomes a race to see who can consume the most obscure thing in an effort to keep people out. This is why gamergate is so threatened, it's diluting the only identity they have because they're so empty of meaningful personhood otherwise.

</comment></comment></comment><comment><USER4> I guess there were better ways to spend the cruise:

[http://gavinverhey.tumblr.com/post/111287496771/the-time- i-f...](http://gavinverhey.tumblr.com/post/111287496771/the-time-i-fell-down- a-volcano)

<comment><USER5> Thanks for that. I'm not even halfway through and I'm very glad I started.

</comment></comment><comment><USER6> > If the JoCo Cruise is a church, I am apostate. That's why I couldn't stop > worrying and love the Sea Monkeys. It wasn't that I didn't want to be a nerd > anymore. It was that I did. Or rather, that I already, inescapably, was. > That boat and those people? They were my hometown.

Poignant article, some echoes in my own life. My nerd cred includes liking comics, Star Trek, computer programming, obsessing about science fiction minutiae, explaining real life using computer/SF/fantasy tropes etc. But somehow never quite belonging with all the cosplaying, filksilking, us against the muggles depth of nerddom. And never quite belonging with mainstream society either -- why do people NOT want an explanation how MCU Bruce Banner can control his Hulk persona, for example?

It's strange this feeling of not belonging. The author identifies this with a former life ("my hometown"), presumably because he's partly outgrown it. While I have outgrown some parts of my nerddom, I've always felt this "not belonging" though.

</comment><comment><USER7> This is by far the most poetic article I've read on Wired

</comment><comment><USER8> Where do you find themed cruises like this? Last time I went on a cruise my wife, sister and brother in law had a blast playing pandemic and D&D, but there weren't too many other geeky people around that I could see (either older people, people with family, or young party types)

<comment><USER9> [https://jococruise.com/](https://jococruise.com/)</comment></comment>


Two Scoops of Django 1.11 Book Released - <AUTHOR> https://www.twoscoopspress.com/collections/everything/products/two-scoops-of-django-1-11 <comment><USER2> 1.8 release was dope, can't wait to snag the 1.11 release</comment>


Mike Ash discusses blocks in Objective C - <AUTHOR> http://www.mikeash.com/?page=pyblog/friday-qa-2008-12-26.html <comment><USER2> Mike used to be really helpful in #macdev on freenode. Haven't seen him in the channel in a while though.

edit: he also flies gliders where my current flight instructor teaches :)</comment>


Linus Torvalds Responds To Microsoft Patent Claims -- Linus Torvalds -- InformationWeek - <AUTHOR> http://www.informationweek.com/news/showArticle.jhtml?articleID=199600443 <comment><USER2> Great response from Linus. A textbook example of FUD [Fear, Uncertainty, Doubt].

_Here's the positive:_

The lame CIO's who believe the Microsoft FUD about linux and decide to go with Windows as their platform will inevitably have a brain-drain of their A-level coders. Once the A-level coders are gone, it's all down hill from there. Their code-base will turn into a Huge Ball of Mud, everything will slow to a crawl and their competitors will eat their lunch. Natural selection! Darwinism at work in the wilds of Corporate America!</comment>


TV Ad Retargeting – Samsung Ads - <AUTHOR> https://www.samsung.com/us/business/samsungads/resources/tv-ad-retargeting/ <comment><AUTHOR> Samsung knows which commercials Samsung TV owners did and didn't see, and uses that knowledge to target ads on TV and non-TV devices. Companies can say "Show my ad/commercial to everyone who didn't see my TV commercial."

Here's how the site puts it:

> How It Works

> Samsung Smart TVs have built-in Automated Content Recognition (ACR) > technology that can understand viewing behavior and usage including > programs, movies, ads, gaming content and OTT apps in real-time. It's a > simple 3-step process:

> 1\. Let us know the brand and title of the commercial spot you would like to > target for your TV Ad Retargeting campaign.

> 2\. The selected commercial is recognized and instantly matched with our ACR > data.

> 3\. Retargeting campaign is activated for the selected TV commercial based > on pre-aligned campaign parameters.

More on Samsung Ads: [https://www.samsung.com/us/business/samsungads/](https://www.samsung.com/us/business/samsungads/)</comment>


Microsoft Hits $1T Market Value for First Time - sahin-boydas https://www.wsj.com/articles/microsoft-hits-1-trillion-market-value-for-first-time-11556201153 <comment><AUTHOR> Just over ten years after "Microsoft is dead": [http://www.paulgraham.com/microsoft.html](http://www.paulgraham.com/microsoft.html)</comment>


[show HN] Closest.in - Represents your closest social graph, the missing angle.  - <AUTHOR> http://closest.in

<comment><AUTHOR> Need some up votes so that we can get more feedback.

</comment><comment><USER2> Login/Registration should be https. No excuses.

<comment><USER3> OT, but: What about "Using Google App Engine" with a custom domain as an excuse? :/

From what I've seen it seems that SSL on custom domains will be a premium feature when it's released.

</comment></comment><comment><USER2> What is the revenue model?

<comment><AUTHOR> User acquisition.

<comment><USER2> So at some point users are the product? The most common way to exploit that is advertisement. Is that what you are doing/will do? If so, how do the projections look? You will break-even when?

<comment><AUTHOR> :) What we are doing is providing a service. Business plans are better kept for later stages.

<comment><USER2> > Business plans are better kept for later stages.

That is a naïve statement.

<comment><AUTHOR> sorry if it felt like that.</comment></comment></comment></comment></comment></comment>


US senator urges investigation into Google+ bug 'coverup' - <AUTHOR> https://sociable.co/business/us-senator-google-coverup/ <comment><USER2> What an embarrassment. Blumenthal should leave the performative infosec policymaking to his colleague Ron Wyden.

It is not and never has been a norm for SAAS vendors to disclose internal vulnerabilities that have not been discovered independently by third parties. Tens of thousands are found every year by internal teams and contractors at companies around the country, many of them far more severe than the G+ bug (which would probably win a sev:low on a real assessment, less impactful than an XSS bug). You hear about none of them.

A coherent argument that this is as it should be: [http://flaked.sockpuppet.org/2018/10/09/internal- disclosure-...](http://flaked.sockpuppet.org/2018/10/09/internal-disclosure- boring.html)

You can argue that things should be different for shrink-wrap software and hardware products, where vulnerabilities have a half-life and users need to be notified to patch. I won't disagree, but I will note that the norm of _not_ disclosing internal discoveries holds there as well.

<comment><USER3> > _Tens of thousands are found every year by internal teams and contractors at > companies around the country_

It's fair to say "Google followed current best practice." It's not fair to say "current practice is how it should always be."

What is acceptable for a company selling razors to Minessotans may not be for a behemoth with troves of personal data on every American. The question, "should Google have heightened disclosure requirements around confirmed and potential breaches," is not invalid.

<comment><USER2> The link I posted does a better job of directly addressing that argument than I could do by retyping it here.

<comment><USER4> So the argument in the linked article is this:

 _" A mandate to disclose internal vulnerabilities would change incentives. Firms would have a reason not to want to find vulnerabilities."_

My problem with this thinking is that it could be extended to finding breaches. If you have to publish every breach you're not going to want to find them.

It's impossible to prove that a vulnerability has not resulted in a breach and so an argument could be made that every vulnerability has to be considered a breach.

That would not be very pragmatic though, especially if we also take the view that every bug is a vulnerability (as the linked article does).

I think if the ultimate goal is to protect users, we can't be dogmatic or formalistic about which incidents to publish. It has to depend on the likelihood and the severity of any damage.

If a vulnerability concerns highly sensitive data and we don't know whether or not there was a breach then users should be told about the incident so they can protect themselves or change their behaviour in the future.

I also think that in this particular event Google tried to downplay the likelihood of a breach. Bad idea.

<comment><USER2> The difference between internal work to find vulnerabilities and breach response is that one is optional and the other effectively isn't. There are incentives at play in breach response as well, but they are attenuated.

And, again: so far as anyone knows, there was no breach. _All software_ is in a continuous state of "likely breach". But words mean things: a breach happens when a vulnerability is exploited maliciously, not when it's discovered.

<comment><USER4> I didn't dispute the meaning of the words, and I agree that making internally discovered vulnerabilities public should be (legally) optional.

But that raises the question which ones should and which ones shouldn't be disclosed.

In my opinion, knowing for sure that there was a breach is not the right threshold in all cases.

A high profile public API that had a glaring vulnerability for years seems far more likely to have been breached than most other software.

Also, the more high profile the software the greater the reputational risk of being wrong.

What if the bug gets leaked eventually? What if there was in fact a breach and it only becomes known later when people have already suffered the consequences?

If that happens, people will question the decision not to publish and the damage to trust will be far greater. This has to be factored into the incentive structure of any disclosure or non-disclosure.

I think the best course of action is to routinely disclose all vulnerabilities but not necessarily alert all end-users to all vulnerabilities.

<comment><USER2> I don't know where to start with this, so I'll just shotgun my answers:

* The vulnerability we're talking about, like all G+ vulnerabilities, has no half-life. It's fixed decisively the instant they deploy the fix to prod. There is no user response we're looking for to mitigate the vulnerability.

* The incentive problem isn't eliminated just because you only target Google with the new norm. When we demand that "high-profile" companies disclose vulnerabilities, we create the sentiment, across the industry and in low-profile companies as well, that vulnerability discovery is a bad event, to be avoided. _The exact opposite thing is true_.

* Internal vulnerabilities in high-profile applications are discovered so often that people will quickly tune them out (until someone sets out to take a scalp). It could even wind up benefiting companies with actual breaches, whose announcements will be lost in the noise, and more easily PR-spun.

The basic problem here is very simple: found- and- fixed vulnerabilities _aren 't breaches_. A vulnerability and its successful exploitation are not the same thing. It does not matter if the vulnerability is "leaked eventually", so long as it's fixed when it's found.

If Google had discovered this vulnerability and then just decided to ignore it for 6 months, _that would be a story_. That's not what happened.

<comment><USER4> _> The basic problem here is very simple: found- and- fixed vulnerabilities aren't breaches._

What makes this less than simple is that we may not know whether or not a particular vulnerability was exploited (i.e if a breach has occurred).

My opinion is that the likelihood of an undiscovered breach and the potential damage of any such breach should be taken into account when deciding whether or not to disclose a particular vulnerability.

 _> The incentive problem isn't eliminated just because you only target Google with the new norm._

I have no interest in targeting Google specifically (I'm actually a shareholder). They just happen to be big and have a lot of personal data. They are in the crosshairs of regulators and politicians as well, which is another reason to err on the side of transparency.

I'm also not trying to eliminate the incentive problem by limiting it to Google (or other big companies). On the contrary, my opinion is that disclosing vulnerabilities in a timely fashion should be seen as building trust and become the new normal. Making it the new normal is what should fix the incentive problem over time as people get used to it.

People tuning out is not a bad thing. The difference between an actual breach and a fixed vulnerability will not be lost just because vulnerabilities are no longer kept secret.

But as I said, I don't think end-users should be notified of every single vulnerability.

<comment><USER2> Any response I could write to this would just be repeating things I said previously.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> Sure. First hold Equifax accountable, then we'll talk about Google.

<comment><USER6> Half the job of a politician is to get re-elected. This is part of that half. There's outrage and standing up for the people against a big company. Someone will be dragged before Congress and get embarrassed publically. And then we move on.

<comment><USER7> This reminded me of a story:

In an op-ed promoting campaign finance reform, the Oracle of Omaha, Warren Buffett, proposed raising the limit on individual contributions from $1,000 to $5,000 and banning all other contributions. No corporate money, no union money, no soft money. It sounds great, except that it would never pass.

Campaign finance reform is so hard to pass because the incumbent legislators who have to approve it are the ones who have the most to lose. Their advantage in fundraising is what gives them job security. How do you get people to do something that is against their interest? Put them in what is known as the prisoners' dilemma. According to Buffett:

 _Well, just suppose some eccentric billionaire (not me, not me!) made the following offer: If the bill was defeated, this person—the E.B.—would donate $1 billion in an allowable manner (soft money makes all possible) to the political party that had delivered the most votes to getting it passed. Given this diabolical application of game theory, the bill would sail through Congress and thus cost our E.B. nothing (establishing him as not so eccentric after all)._

Consider your options as a Democratic legislator. If you think that the Republicans will support the bill and you work to defeat it, then if you are successful, you will have delivered $1 billion to the Republicans, thereby handing them the resources to dominate for the next decade. Thus there is no gain in opposing the bill if the Republicans are supporting it. Now, if the Republicans are against it and you support it, then you have the chance of making $1 billion.

Thus whatever the Republicans do, the Democrats should support the bill. Of course, the same logic applies to the Republicans. They should support the bill no matter what the Democrats do. In the end, both parties support the bill, and our billionaire gets his proposal for free. As a bonus, Buffett notes that the very effectiveness of his plan "would highlight the absurdity of claims that money doesn't influence Congressional votes."

This situation is called a prisoners' dilemma because both sides are led to take an action that is against their mutual interest. In the classic version of the prisoners' dilemma, the police are separately interrogating two suspects. Each is given an incentive to be the first to confess and a much harsher sentence if he holds out while the other confesses. Thus each finds it advantageous to confess, though they would both do better if each kept quiet.

From the book The Art of Strategy. Great book.

<comment><USER8> The prisoner's dilemma hinges on lack of communication between the prisoners. In the original scenario, communicating prisoners would both choose to stay silent. In the above scenario, communicating politicians would choose to never let the bill out of committee.

<comment><USER3> > _communicating politicians would choose to never let the bill out of > committee_

This presumes every politician is equally dependent on outside financing. Self-financed and small-donation financed politicians would be politically incentivized to bunch together and knock the legs out from under the competition's money machine.

Politics is complicated. Condemning campaign finance reform is premature. (Saying it's a tough fight would be accurate.)

</comment></comment></comment></comment></comment><comment><USER9> So not only should companies have to publish hacks, they also have to publish when they internally find a bug?

Do I also need to publish if I left my keys in the door for two hours, but nobody broke in?

<comment><USER10> How do you know nobody broke in?

And if you're responsible for storing personal data for millions of people in your home, and you left the keys in the door for a few hours, and you can't prove that nobody broke in, then maybe you _should_ let people know that there's a chance their data has been compromised.

<comment><USER11> Server logs are more or less equivalent the video recordings of the front door in this analogy. So the answer is you can know that nobody broke in by looking at the logs/recordings.

<comment><USER12> Google explicitly said in their post that they don't have more than two weeks of logs (ironically, for privacy reasons).

</comment></comment></comment></comment><comment><USER13> It's a really shitty job by Google PR people. Who in their right mind would close product in response to a security vulnerability? It was bound to grow out of proportions.

Headlines like "500 000 people at risk! The bug was so serious that Google shuts down their social network!" just write themselves.</comment>


Discover great European startups for investment - <AUTHOR> http://globalinnovation.co/

<comment><AUTHOR> > _Start-up funding raised is much lower than in the US._

> _The number of US. and European start-ups is comparable. However, European > start-ups only raised 23% the amount raised by their US. counterparts._

This is the second biggest problem we have in Europe, we cannot compete with startups experimenting new markets with 2-3 even 4 times the financial power of an European one.

> _Early-stage exit valuations are much lower than in the US._

> _Early stage exits are valued 16%-20% the amount of the US. counterparts. > Comparatively lower funding for latter stages and fewer buyers, relative to > the US._

This is the biggest problem, we cannot solve the first one, without giving to investors a real opportunity to exit. We continuously miss this point, no exit means no money, how an investor can put money on something the exit is very difficult?</comment>


12 awesome sci-fi themed lunch boxes - <AUTHOR> http://io9.com/5547925/12-awesome-science-fiction-lunch-boxes/

<comment><USER2> I object! The Hulk, Superman and Clash of the Titans do not qualify.</comment>


We're making visual feedback simpler. - <AUTHOR> http://blog.awesomebox.co/post/73349850674/were-making-visual-feedback-simpler

<comment><USER2> Here's some visual feedback:

        Application Error

        An error occurred in the application and your page could not be served. Please try again in a few moments.

        If you are the application owner, check your logs for details.

<comment><AUTHOR> Sorry! We hit some momentary downtime on Heroku. Back online now.

<comment><USER2> Thanks :)

</comment></comment></comment><comment><USER3> After using [http://bugherd.com](http://bugherd.com) for a while, I find this uncomfortably close. The icon-based side nav, the drag selection, the overall colours and theming. I'm not making any accusations, but I think it needs to be said that it's the first thing I thought of.

<comment><USER4> I appreciate the sentiment, but I do think it's quite a bit different to what we at BugHerd do. BugHerd is designed to run ON your site, rather than your site running IN BugHerd.

We originally went down the awesomebox path, but as soon as we started dealing with server side code it caused issues. We run on your production/staging environment meaning you get your app running in the wild.

</comment></comment><comment><USER5> I don't think I quite understand what Awesomebox is. Is it packaged staging server with built in commenting functionality? What type of code can be pushed to it? Why is it that you push code your way rather than install a widget of some kind in existing staging environments?

<comment><AUTHOR> Think of Awesomebox like a versioned CDN - you can push any HTML, CSS or JS, and then invite anyone to view, comment and annotate it.

It's different from a widget in that Awesomebox gives you infinite staging environments - if you push 10 different ideas, and then invite a few people, they can easily switch between different versions without you having to manage multiple servers. In our experience, this is really important when working through new ideas or designs with clients or managers.

Does that help answer your question? Happy to explain more if not.

<comment><USER5> Got you. That does help a bit. I do think there is something interesting here. Today I spent time reviewing and commenting on the interface screens of an OpenID implementation currently in development. I wonder if there is some sort of proxy or browser extension you could employ to capture the HTML state of dynamically generated content. For us, this portion of the site never went through a static mockup phase.

<comment><AUTHOR> That's a great example - we're certainly thinking about how to balance the power of static assets, which let us display a few different versions, versus supporting generated content from web servers like Rails or Django, where we can only display what's on your server.

Really, really appreciate the feedback!

</comment></comment></comment></comment><comment><USER6> It took me awhile to get, but my aha moment was understanding its relationship to regular PaaS's (eg: heroku).

What more could you do if you didn't need to deploy your entire stack with each little change you make? If you could only deploy your frontend (in different versions simultaneously) pointing to a backend that's always up, it enables much faster iteration: testing, bugfixing, demoing things that otherwise you might not deploy different versions for because it's too painful.

For example, you could A/B test meaningful portions of frontend code in a more scalable way than, say, Optimizely. Or you might point a user that's having problems to a specific build (which you can deploy instantly) and see if it fixes their problem _on their live account_. Or you can hack together a new feature that works _on a live account_ for a presentation, and push it without worrying about mucking up or interrupting production traffic. Or turn off minification instantly and deploy that.

Plus, you don't have to worry about refining internal frontend build scripts, it's plug and play.

</comment><comment><USER7> Very cool! This is very very similar to the feedback and annotation feature I'm working on for our product. There's a clear need for this capability to comment (and draw) directly on the design. It just makes it so much easier to talk about something when you literally talk around it.

My inspiration for the feature was that feeling I always got that I needed to walk over to someone's desk and show them what I'm working on on my Macbook or paper and talk through it. Sometimes you can't do that if the team is remote or a client needs to check something out, so you need an approximation of that experience. Making a product around the feature is a great idea.

<comment><AUTHOR> That's awesome! Totally agree about remote work - our inspiration came working with people across multiple timezones, and not always being able to walk over and show them.

I'm curious - what's the name of the product you're building?

<comment><USER7> It's Handcraft, a HTML prototyping app. Link is in my profile.

<comment><AUTHOR> Cool! I'll check it out.

</comment></comment></comment></comment><comment><USER8> What kind of pricing structure are you looking at?

Also Windows/FF gets an invalid font character for the "v" arrow on the grey tab. Works ok in Chrome/IE

More once inside the app: [http://i.imgur.com/WFaLbjw.jpg](http://i.imgur.com/WFaLbjw.jpg)

<comment><AUTHOR> Sorry about that! Offhand I think that's a unicode issue that I need to fix. Thank you for the heads up. Will work on a fix tonight.

As far as pricing, we're not sure yet, but we want to make it as free and accessible to developers and designers as we can, and charge companies, not people - kind of like how Github is free for open-source projects.

<comment><USER9> firefox doesn't allow cross domain fonts w/o allow-origin

</comment></comment></comment><comment><USER10> Tried to install, got an error, looked at the stack trace and saw this:

        at module.exports (C:\[snip]\npm\node_modules\awesomebox\node_modules\awesomebox-core\__trojan__\horse.js:15:10)

What. The. Fuck.

Could not possibly uninstall fast enough. Running antivirus ASAP

<comment><USER11> I promise this isn't a trojan horse! Trojan is actually an npm module that allows you to compile down nodejs code so that you can package it all as a single downloadable.

Check out trojan here: [https://github.com/mattinsler/trojan](https://github.com/mattinsler/trojan)

This helps with managing download times for all the transpiling code that we use for things like coffeescript and less and ejs.

At the time I wrote this module I thought it'd be funny to name one of the files horse to continue the joke. Definitely time to change that filename. =-)

I'd be happy to walk you through how all the code works if you're interested.

<comment><USER12> Matt, you have two problems here I think you need to fix:

1\. Your "trojan horse" name for that packager - has two connotations for me, neither of them good. Why not just call it what it is.

2\. Your product name. I really couldn't recommend your product to anyone doing serious work for my company or my clients. The whole "awesome" and "ninja" vocabulary thing is grating, is done to death, I am sick of hearing it. My advice is to pick a better name if you want to attract anything more than tyre kickers.

Pretty sure you put a lot of time an effort into this, don't blow it with stuff like this.

</comment></comment></comment><comment><USER13> Nice work guys, looks very useful

<comment><AUTHOR> Thanks Des! It's come a long way since we showed you guys last month. Matt and I are very happy intercom users over here too :)

</comment></comment><comment><USER14> Your video is falling out of the laptop screen, to the right side, on an iPad air.

<comment><AUTHOR> Thanks for the heads up! Working on a fix right now.

</comment></comment><comment><USER15> Looks like it does the exact same thing [http://notableapp.com/](http://notableapp.com/) does.

<comment><AUTHOR> Similar, but not quite - notable is focused on design prototyping and wireframing, but our goal with Awesomebox is to follow a website throughout its lifecycle, not just during the initial design phase. I'm a big fan of ZURB though - their products are great and I've enjoyed working with the Foundation CSS framework.

</comment></comment><comment><USER16> Why are you guys working past 1am? Get some sleep, feedback can wait in the morning!

</comment><comment><USER17> Looks like it's similar to, if not the same as www.designdrop.io.

<comment><AUTHOR> Not quite - Awesomebox works with your real production code, whereas DesignDrop is only for design files like PNGs, JPEGS and PSDs.

</comment></comment><comment><USER18> Bro! I tried to sign up with Google and it looks like maybe just maybe your OAuth is broken! Dogfooding.

<comment><USER11> You're absolutely right! We're so sorry about that! It's fixed now. Thanks for finding that!</comment></comment>