Ask HN: What's with all the unpaid interview projects? - <AUTHOR> From the smallest startup, to Google, almost everyone I've ever interviewed with has required unpaid project work.
I rarely, if ever, get feedback on these projects.  In later rounds, it's obvious most interviewers haven't seen the project or even know you did it.
Why is software engineering the only industry I'm aware of that requires you to prove that you know how to do things you've been doing for years and years? Your projects on Github, degree in your field, and resume don't matter and are rarely discussed.
Unpaid projects, over and over.
Companies are too lazy to do their own work and we are all getting screwed.
How many hours of free work have you had to do, only to get ghosted, denied without feedback, or see your work turn up in their product later?
It isn't that hard of a problem to fix:  stop being cheap and pay people for their time.
"But we can't afford it..." - nonsense!  Esp. big companies.  Poppycock.
If it's "too expensive", you need to have a better funnel upfront before the project stage.
Properly compensating for interviews would be a huge differentiator for recruiting.
Great engineer A: "I interviewed at Company X, and didn't get it.  But they paid me $1000 for a day's work.  It was pretty cool."
"Rockstar" engineer B: "Wow, that sounds neat. Too bad you didn't get it!" (Maybe I'll interview there too...)
vs. ill-will from unpaid
Great engineer a: "Yeah I interviewed with company X and they made me do a 3 day unpaid project.  I didn't get any feedback and they made me do a technical interview AFTER I had already submitted the project, where they just asked unrelated trivia.  One line rejection e-mail."
"Rockstar" engineer B: "Yeah that sucks.  They sound awful.  You dodged a bullet" (continues working where they are)
If I do work for you, pay me for it. If I do work for you, give me feedback. If I do work for you, respect my time. <comment><USER3> I couldn't agree more - and it impact how we hire. I refuse to give someone a "take home test"; quite frankly it reaks of a lack of respect for the candidate. Interviewing is two-sided, the organization has to check out the candidate and the candidate has to check out the organization.

Our last hires were brought in for a two-part interview, on the same day. The first was an interview to ensure the personality fit was there, to ensure that the differences we all bring to the table could be a strength.

The candidates were then given a running API server, a postman collection, swagger docs, and an empty directory. We asked them to solve a specific problem - one that we already showed the candidate is solved in production, one we make clear cannot be solved in the two hours they're given. Then, the candidate is encouraged to work on the problem, and ask questions.

Multiple team members check in on the candidate throughout the period, in order to offer support, suggestions, pick things apart, and be a sounding board. Then, when things are done we sit down as a minimum of three people (candidate + 2 staff) to discuss the output and outcome.

This isn't the most fair, and can definitely be stressful. At the same time, I feel like it's pretty equitable.

<comment><USER4> >> Our last hires were brought in for a two-part interview, on the same day. The first was an interview to ensure the personality fit was there, to ensure that the differences we all bring to the table could be a strength. The candidates were then given a running API server, a postman collection, swagger docs, and an empty directory. We asked them to solve a specific problem - <USER2> that we already showed the candidate is solved in production, one we make clear cannot be solved in the two hours they're given. Then, the candidate is encouraged to work on the problem, and ask questions.

As someone who did a few interviews last year, I wish they had been like this. I walked away from most interviews when they started asking me things like:

\- "I dont really have time to think up any interview questions or a test so can you bring some code from your last job and we'll take through it..."

\- Asked me to do a 2 hour online test without having even spoken to me in any capacity, or asked me to do a homework quiz "it should take around 10 hours" before having spoke to me in any capacity....and they were the ones who contacted me initially.

My favorite was hiring me as a contractor on a short term basis, paying market rates, and then using this time for us to see if we were a good fit.

<comment><USER3> I appreciate this. The reality though is that there's no setup cost for this. Our team always has a back end that generates swagger - and swagger to postman is a quick command. The most "expensive" part of the setup was creating a new user on the laptop that sat on the desk.

</comment></comment></comment><comment><USER5> Small companies as well do this. I've had an interview where the CEO just called in their lead infrastructure guy to join the "conversation" and it turned out to be a free consultation session which I could have easily charged a good number on a normal day. After almost 5 hours of this interview I was told I'll recieve a response on mail. 2 years later still nothing. Company in question: Skalogs/Sentai

<comment><USER6> wow 5 hours.. 2 years..

</comment></comment><comment><USER7> I follow a simple rule about this when I'm the interviewer - any time commitment asked of a job candidate to write code, must be matched by an equal time commitment on my part.

For example, that permits collaborative code questions or white boarding, but not take home code challenges. Past experience has shown me those are always horribly estimated, and require more time on the candidate's part than issuers claim. Put yourself in the candidate's shoes, having 3-5 of these things to work through (unpaid, no doubt, as OP rightfully objects to). Not fun!

I've found that rule a simple, transparent, way of showing respect for candidates' time. Which I've always found admirable, from both sides of the hiring table.

<comment><AUTHOR> Thanks for committing time and communicating clearly. Short of getting paid, it sounds like you're respecting candidates, so that's something! :)

</comment></comment><comment><USER8> Unpopular opinion: Interview problem is a solved problem for software engineer candidates for majority of use cases, it is called Data Structures and Algorithm.

Yes I've tried the other two: take home tests, work one day at company X. They all suck. They all optimized for the suffering of the software engineer candidates. You can't do multiple companies take home tests, it is a waste of time. You can't do multiple work one day at company X, Y, Z. Waste of time. And after all of those time wasters they still reject you for non obvious reasons such as cultural fit, pay, seniority level, etc.

Just cut to the chase, give me DS & A questions and be done with it.

Data Structures and Algorithms are the best mean to interview. Study once, apply multiple times to multiple companies and kill those and get multiple offers, with bonus it makes you a better engineer (at least in my case), though later it gives diminishing returns. You can jump companies every year easily with this skill.

But then people will ask, "how does that gauge software engineering skills?" or "what if you aren't good at data structures and algorithms but you are good at something else like design, product, css, etc" or "there are more to working than just data structures and algorithms" or "you will get similar people in your talent pipeline".

I don't know, that's not the problem of the software engineer candidates, that's the problem of the companies. Let them deal with it. We software engineer candidates just play the game, get the job or rejected from the job, and do the job, go home, collect paycheck, sleep, play, exercise, use our mind, talent and energy doing something else.

<comment><USER9> I agree with some of your points. The problem is that a lot of engineers are just not good at DS puzzles under that kind of pressure in that amount of time. Also that's totally unrealistic and is not how Software Engineering works in real life. In real life you have group discussion, design sessions, time to think without the pressure of having to talk the whole time spitting thoughts, etc. I think some companies are starting to do pair programming and design sessions during the interviews. That sounds more appropriate to me. But it's also more expensive and time consuming.

<comment><USER8> If I can give you some encouragements,

I don't consider myself good in DS&A puzzles. My definition of good in DS&A puzzles is basically you can solve common/most Hard Leetcode problems in under 45 mins. I think if you can do this you'll have no problem jumping ship of FAANG-league companies every year. I am still not in FAANG.

My skill now is pretty much in Medium Leetcode problems, which I can solve common/most of them in under 45 mins. I used to be worse at this and couldn't even solve Easy problems for 2 hours. I just practiced and practiced and studied, until it becomes easier.

Now, what this skill gives me is, I can easily knock off majority of non FAANG interviews out there, in under 30 mins. In my last interviewing with companies I actually did most of their questions each in under 15 mins. This leaves them to talk about something else such as projects, past responsibilities, cultural fit, or even just dismiss the interview altogether to save everyone time.

DS&A interview is in a sense, sort of a pair programming/discussion thing because you need to voice your reasoning out loud to check with the interviewer that you are going in the right direction.

Also once you practiced these kinds of questions, then it is no longer "I need to find a new solution to this problem", but more "ah I see this question before and I know how to solve this". It is pretty much almost brain-dead at this moment. Like, dynamic programming, recursion, and BFS/DFS are pretty much very mechanical. Once you've seen a few patterns, then you can tackle most of it.

Yes this skill doesn't come easily, but once you get it, you get it. So the difficulty of attaining this skill is overrated. It is like swimming and driving. Once you get it, it takes a few weeks to ramp up again. Weighing the pros and cons of DS&A compared to other style of interviews, it is clear to me which is the winner to optimize my happiness and lessen my sufferings. It is cheap to execute, it works majority of the time.

If a software engineer realize this reality and start playing the game, he/she is already ahead in the curve by a few miles from other candidates.

Ironically, I actually don't want most software engineers to realize this, because this skill currently gives me an advantage. If everyone start doing this, then the interview bar will be raised higher and we as an industry will see other practices which are optimized for software engineering candidates suffering.

<comment><AUTHOR> it's a stupid game but you're smart to play it.

but if DS&A puzzles are a de-facto standard, why not have an actual standard? the whole thing is pretty haphazard.

it's like hiring someone to be your defense attorney because they're decent at the NYT Crossword Puzzle, or to be your doctor because they're good at Sudoku.

<comment><USER8> It is like most things in life or software, no silver bullet. Every team/product/company has different requirements that they need to fulfill, including off-the-mark measures such as diversity quota. Having an actual standard will make it difficult. Besides, this field moves so much nobody wants to get certifications that will be obsolete 3 months down the road. Not to mention certifications and credentials can be bad gatekeeper in itself.

This game is actually really easy to play, much easier than any other corporate/job game in other fields. You just need to know the rules, study the rules and get on with your life. You don't need bachelor/master from expensive universities or any other gate-keeping b __s __t like in medical or law.

I wasn't born rich or smart or have good connections, and I'm glad setting aside a few months to study DS&A can make me earn what most Americans or the world envy. Much more if I'm good at it so I can jump ship at FAANG every year and living the dream. Let the rich/smart/well-connected people solve harder problems such as medicine or law. I just get on with my life.

</comment></comment></comment></comment></comment><comment><USER10> I've been open sourcing my take home tests: [https://github.com/tlhunter?utf8=%E2%9C%93&tab=repositories&...](https://github.com/tlhunter?utf8=%E2%9C%93&tab=repositories&q=take- home-test&type=&language=)

Not sure if there's any legal implications with this, like, say I own the code but the company owns the "idea".

<comment><USER11> Unless you've been paid for it (work for hire) your work product is your own.

<comment><USER12> Can you change that contractually in the US? I know here you can. And if you are a freelancer, you can have default company terms which say you own it all, even when paid. I had very few changing that default contract and my last few paid jobs rather did a 'partnership' as in shared ownership for a lower hourly with an option to buy outright for shares and/or money at a later date.

There are more ways to skin a cat. I am not sure big ( especially software) companies (in other, more litigious countries than mine) would entertain things like this, but if you do not try...

For instance, I did a small intranet for a very large company (for my country); because it was not their core business, and as such they did not care if we kept the (c) or sold the source to others as long as they had eternal perpetual rights to do whatever with it as long as they do not sell or use it outside their company. They reasoned that if I have more clients, they might get features and/or bugfixes for free. They did, up to some point and it made me turn my 1 man services company into a product company with staff. Which was fun but a steep learning curve, especially with regards to the money required for the growth of such a company.

Their lawyers made up a very fair contract (again this was not their core business so they genuinely knew they would never want to sell this themselves) which had clauses to protect them and us if they exited etc.

I had this happen far more often; at the right level, many companies, especially none software companies, will be up for this if they benefit financially or otherwise. Recently (different company; only services again) I had a large car maker suggesting we sell a small LoB app we made for them to their competitors so they would, again, share the financial pain of bugfixes and intellectual gain of new features. Kind of a product/services mix without the pressure of roadmaps, growth etc (all companies pay per hour and get all versions, including forks for others, but not forks by others unless the other parties specifically agree). So kind of contained-closed-open-source way of working, which is far easier for the corp lawyers to wrap their heads around than throwing things into the actual open. Also the quality demands code, community wise, are far less important. Let's be real; most LoB software is a burning heap of crap; usually first put together parttime by someone of the departmental business and then passed to an external company when growing out of bounds (getting too much uptake internally). This time we could basically do a rewrite, but that is not always the case (remember; my business is being paid for every single hour).

</comment></comment></comment><comment><USER13> I graduated college last year and I did quite a few of these unpaid interview projects. They never took more than a hour and all of the projects were clearly not intended to actually be used in real life projects. The projects are clearly there to see if I could follow the written spec and write reasonably efficient code which I think is reasonable.

If the take home project looks like something the company would actually use in their codebase, then yeah I would probably ask for compensation.

<comment><USER14> I think if you're just getting into the industry, and if the projects are actually of small scale, then they're arguably more reasonable. If you have a resume with stuff on it and can talk through it, it's less so. Most of the ones I've seen have required way more hours to do reasonably well than the estimated time, and it's ridiculous to have every candidate prove themselves equally with some trite project.

</comment></comment><comment><USER15> I feel like interviewers can't win here: no matter what, Hacker News will complain about it. HN says whiteboard questions are terrible, leetcode is terrible, Github resumés are terrible, take-home projects are terrible... these are all defensible arguments in isolation, but what _should_ interviewers do? There's a lot of griping re: interviewing but few suggestions on what to do instead.

<comment><USER16> I can tell you what's worked for me when hiring experienced programmers:

Ideally the candidate offers code samples, I then pick through the code samples to find things that strike me as unusual or problematic and ask questions about those parts. This gives me a great deal of insight about how people think, and their relative level of skill. I firmly believe this is the best way to interview.

Failing that, candidates frequently provide details on projects they worked on. I'll then ask questions about those projects like, "What language did you develop it in and why?" and "What do you think was the most difficult part about this project and why?" These questions are a gateway to the same kind of details you get from code samples. For example, a candidate once mentioned he had worked for the Navy, and had done water simulations for them and I asked, "What's so difficult about water simulations?" and he gave me a 20 minute lecture on how water simulations work, which won him the job. It's probably worth noting that the job had nothing to do with water simulations, but his lecture made it clear he had passion and knowledge and could do the job.

The worst interviews are ones where the candidates worked in an environment where they can't offer code samples or talk about previous projects (military contractor, for example) - these you just kind of muddle through by talking about programming in general.

<comment><USER17> The problem with talking about previous projects is that it can be hard to tell whether the candidate was an important contributor to the project or just a subpar developer making the changes (s)he's told to do by more knowledgeable teammates. A candidate which is charismatic and good at talking can be quite convincing.

Provided code samples is good, but only if the candidate has written all the code themselves and isn't just passing off other's code on a project as their own.

When I was conducting interviews I was frequently surprised by just how bad some candidates with fancy titles and a decade of experience were at actually coding. And I mean things like a understanding a simple recursive function, integer division, inheritance and other core concepts. I would never hire someone without at least a brief code comprehension check nowadays.

<comment><USER18> The problem is you'd probably do just as poorly under the gun and away from your subject of expertise.

</comment></comment></comment></comment><comment><USER19> I don't think of it as "unpaid work".... Unless you think they are turning around and using it...

As a noob that is bad at interview programming trivia I've really enjoyed the interview projects I did.

Granted they were hardly a lot of work, but I felt they did a far better job at showing what I can do than all the programming trivia out there.

</comment><comment><USER20> We've had really good success giving a _short_ programming project to candidates, but with caveats:

1\. this follows an extensive screen, where we have a strong signal whether the candidate is a good fit

2\. the project isn't "offloading a current project" to someone to do free work for us; it's marginally related to our core product but pretty generic

3\. the project is explicitly meant to take at most a few hours (we even use this as a way to gauge whether a candidate tends to over-engineer things)

4\. we do a proper code review and architecture discussion after the candidate has submitted an implementation; we take as much time and put as much effort as with production code reviews; we probably put in almost as much time evaluating the candidate as much as they take to do the assignment

All this has worked pretty well for us, a mostly remote team, where interviewing has its own difficulties.

<comment><AUTHOR> "3\. the project is explicitly meant to take at most a few hours (we even use this as a way to gauge whether a candidate tends to over-engineer things)"

i think this is great - time limits help both sides, but companies don't tend to use them that way.

</comment></comment><comment><USER21> I paid a prospective candidate for project work like this. It was more than the market rate for the role they were applying for. For context, this was in India, and I'm also Indian, and so is my company -- this was not an offshoring/outsourcing thing. They disappeared for a month, sent me 20 lines of python that did not work and demanded payment. I made the payment, as promised. Obviously, I did not hire. For a small company like mine, which I'm funding from my own pocket, I don't think I can afford too many candidates like this. I've stopped that practice. Now I only hire people I've worked with on previous jobs before. I know the quality to expect and I know the price I'll be paying.

<comment><AUTHOR> I'm sorry they wasted your time and money. I think if someone disappeared for a month that would break the expectation of payment, but a small contract would settle that.

<comment><USER21> The cost of litigating a contract would have far exceeded any value I could have possibly gotten from the project. The distraction and reputational damage from the ensuing fight would have been even worse. The best policy was to be be polite, and make the payment promised and move on. No need to belittle or argue with the candidate. I chalk it up to a learning cost in the business. I now know one way of hiring that won't work for me.

The irony is that the project had no value to me. I had already implemented that feature, and just wanted to understand if the candidate would be able to do the work I'd already done for myself. Indeed I picked the problem because I had solved it myself under timed conditions and knew how long it would take me. I wrote the code for the feature in about 20 mins and then tested and checked-in under an hour. I expected that a new person with less experience and skill than me would take about 3-5x the time, and that would still be okay. Even if they took a day that was not an issue for me. Which is why I paid them for one day of their time. They might have taken a whole day. But 30 days was somewhat too long. Thankfully I'd priced it at a fixed cost. So my downside was fixed.

Still the learning was not cheap. I was paying what would be considered consulting rates in India.

<comment><AUTHOR> Hopefully you can find a standard contract template online that you can use without having to pay much, if anything. A contract would have had a specific date the result was expected, and if the candidate breached that, it would have clearly been their fault and you wouldn't have had to pay anything.

</comment></comment></comment></comment><comment><USER22> If you haven't licensed your code to them, they shouldn't be able to legally incorporate it in their product. (Although perhaps you implicitly or explicitly gave them permission during the interview). But this is usually not very relevant as you probably will never know whether these companies are using your code or not.

If you only want to prevent companies from using your code in proprietary software, you could send them your code with a GPL license.

Copyright aside, yes, unpaid length projects during interviews are an atrocity.

<comment><AUTHOR> Definitely no license given. Additionally I usually throw an "all rights reserved" on there somewhere to acknowledge my authorship and ownership of the product.

That's great for code + the specific execution of it... for me I often have to also do design engineering and content/concept prototyping as part of these projects. Creative work in addition to the code. I'm not sure there's a way to protect those ideas the same way you can the code.

</comment></comment><comment><USER23> I'm a consultant and have a practice of asking to be paid for these kind of silliness. If the company want they can look at my github profile instead.

<comment><AUTHOR> How many companies have paid you?

</comment></comment><comment><USER6> I've had the gall several times to ask that they pay me to do one of these mini projects but it never resulted in another interview round. And I've actually by now, developed a portfolio of mini projects and try to point there but that hasn't worked. Ironically it only worked with YouTube who moved me to interview in person and in front of a whiteboard instead. As an engineer, you can't win. Go figure.

<comment><AUTHOR> Yeah so many people saying "I tell them I won't do it," without saying how many positive responses companies give them for their principled stands. I'd imagine it's because almost no companies continue with an interview after that point.

re: YT - welp, out of the frying pan, as they say lol

</comment></comment><comment><USER9> Many Software Engineers haven't internalized this concept of time value. A lawyer or a doctor would never do real work for free as part of an interview process but for some reason we don't see it that way when it's about writing code.

<comment><AUTHOR> interesting observation! makes sense. i wonder if it's because engineers are generally salaried instead of billed hourly. given all the 'crunch' and unpaid overtime, we'd be a lot more expensive hourly - folks might realize their real value. instead we give free overtime and then extend that into free interview time

</comment></comment><comment><USER24> I have reviewed two take home programming tasks. for both of them, there was a high correlation between submitting quickly and passing. so I guess if you're down to the wire and spending all your time on the problems then you're not gonna pass anyway.

also they are by far the easiest way to screen people who will fail later. isn't that ideal?

<comment><AUTHOR> no, doesn't sound ideal to me. you probably don't need a take-home.

how much time are you expecting / "giving" candidates to work on these take- home programming tests? it sounds like you're wasting lots of people's time by putting a gap in between your certitude that someone who finishes in X amount of time will be hired and not "fail later", and the Y amount of time total. If you're not going to hire someone beyond the X value, you need to downward adjust your Y until it is the X. Otherwise you're literally wasting people's time.

No, that's not ideal.

Also: do you pay them for their time?

</comment></comment><comment><USER25> For me, it all depends. If I get to skip directly to an on-site and skip the whole phone screen business, I'm willing to do a short (1-2 hour) take home type task. If it's longer than that, and/or it's in addition to phone screens, etc. my willingness is directly proportional to how much I need a new job.

</comment><comment><AUTHOR> Isn't a much better use of VC money than all the ads -- or platforms like Hired, Angelist A-list, etc -- to just, you know, pay candidates directly? What's your cost for a recruiter to get a new candidate? 10% of first year salary of 120K is $12,000.

P.S - whiteboard interviews are also terrible and unpaid.

P.P.S. - "platforms" that whiteboard- e.g. Hired, A-list, etc - are also unpaid and terrible, at scale.

P.P.P.S. I'm not sure what the solution is but I know it has something to do with actually getting to know the PEOPLE you are interviewing. We're all individuals with unique histories. Pay me for an hour or two to tell you my story and you might be surprised at what you learn.

<comment><USER26> There are some solutions out there for people that do not want to do whiteboard algorithms or take home projects. There are interview processes like codebase-projects [0] which you contribute to a company repository. Most companies pay you for the day. There definitely seems to be something wrong, in that a lot of companies don't bother at all in getting to know you. But there are a few out there that do make interviewing a two-way street, and make you feel like you aren't wasting your time.

[0] [https://introview.io/processes/codebase- project/](https://introview.io/processes/codebase-project/)

<comment><AUTHOR> thank you so much for the link - it's great to know that companies exist that are trying different things. showed it to my friend and he said, "Only 9 companies do that!? In the whole world!??!" :/

</comment></comment></comment><comment><USER27> It's not free work.

No company gets candidates to do coding tests as a way to get productive real world tasks completed.

Just don't do it when a companies test task is too onerous.

<comment><AUTHOR> I work and don't get paid... It's free work. whether it gets used or not by them, I spent my time doing a task that was directed for me. That's work.

</comment></comment><comment><USER28> Actually there is a legal problem here- if you are not an employee you must be able to provide an invoice, which most of us cannot.

<comment><AUTHOR> What do you mean? You can whip up an invoice in Google docs or use a service like Wave or something for free.

The trick is: who do you send the invoice to, and will they ever pay it?

I've invoiced companies that made me do unpaid projects and while it makes me feel better it has never once gotten me paid.

<comment><USER28> > You can whip up an invoice in Google docs or use a service like Wave or > something for free.

The invoice is not the problem, handling taxes is. In most countries (I'm not an American) an Invoice means that you are self employed and that you should pay taxes on that part as self employed.

There are services around it that charge percentage of the transaction and I'm not sure will handle such small amounts.</comment></comment></comment>


Five VCs discuss how no-code is going horizontal across the world's industries - dmch-1 https://techcrunch.com/2020/08/22/five-vcs-talk-about-how-no-code-is-going-horizontal-across-the-worlds-industries/ <comment><AUTHOR> This title lacks click-bait and isn't outrageous enough. Try this:

'Five vultures having a round table discussion on how to plan on feasting on no-code startups.'

Also 'no-code' == 'using someone else's code on the cloud.'

Has been called the 'next big thing' since the 2000s and yet here we are.</comment>


Ask HN: The best answer you can give to "Why are you doing this startup"? - <AUTHOR>

I am repeatedly asked "why you and why this startup?" when talking to people about what I'm doing. VCs and other startup experts always kick off with this question. I get through the answer but always feel "because it's an interesting problem" is what it boils down to.
What are the best answers given by entrepreneurs to the question: Why you and why this startup? <comment><USER2> When anyone ever asks me that I say: "why not". Then I tell them "do me a favor and lets skips the bullshit questions". Then I start talking to them about things that actually matter like: How much profit we've made, what our run rate is and what can happen. The bottom line is, when you actually make a profit, at least a couple of thousand no one is gonna ask you those useless questions.

<comment><USER2> I guess what I'm really getting at is entrepreneurs start companies to make money period, they don't start companies for fun or any other crap you hear. When I say: "lets skip the bullshit questions" I guess it lets them know I value my time and the reason I started a company was to make money or else I'd be into non-profits. People don't accidentally get paid in startups they know they're gonna get paid doing something and the successful ones don't just charge enough to make a modest living either.

</comment></comment><comment><USER3> If you're talking to VC's, the answer that got us the money, was:

"We really felt there was an opportunity in the market for a well underwritten product. That could claim a sizable share of the userbase for (your app here) and we believe we can leverage that userbase in to a profitable business generating revenue (or EBITDA) of X by X"</comment>


Scraped without credit - <AUTHOR> I submitted an article here:
https://news.ycombinator.com/item?id=12998899
Idly I did a search for some of the text, and this popped up:
http://www.itdadao.com/articles/c22a774394p0.html
Yes, someone has scrapped the text, copied the images, and put the entire text up, wholesale, without credit.
Should I be surprised?
(I've not added clickable links in the comments because I don't want to give them the traffic.) <comment><USER2> If you want to take action against this scraper, just report them to Google for copyright violation. Google will likely shut off their advertising revenue.

<comment><AUTHOR> Thanks for your reply - useful idea. However, going through their process it appears that I need to have a Google account. I don't have one, and don't want one.

I can find no way to proceed.</comment></comment>


Learn Lisp the Hard Way - <AUTHOR> http://learnlispthehardway.org/ <comment><USER2> I don't want to be too mean, but it looks like very little has changed since the six months or so when this last popped up on HN. The book still has none of the exercises that the exposition places so much weight on. Meanwhile, the introduction still mostly tells rather than shows—for all the discussion about how LISP is an elite hacker language, there are no actual examples backing up that statement (IS it in fact widely used by hackers?). Telling me how great LISP is and rambling on about Heinlenian mysticism is not going to work if theres no real substantive material.

<comment><USER3> Agreed. I bookmarked LLTHW a few months ago when I decided I "need" to learn a Lisp (if, indeed, one can ever be said to truly know a Lisp), but found the extreme WIP-nature off-putting. I think it will be a good resource in a few more years, though.

In the meantime, I've had GigaMonkeys.com open in a separate tab ever since and plan on purchasing the silly "Learn Lisp Through Games!" book.

Edit: But I did find the author's nouveau mysticism/occultism quite interesting. I tend to forget that those belief systems are still around.

<comment><USER4> This is slightly off-topic, but I think it's worth explaining that I don't have a "belief system", per se. I'm a deductive thinker (which I realize is weird for a programmer), so I find metaphor and allusion to be useful tools for explaining myself. Mystical language, in particular, is very rich, colourful, and goes hand-in-hand with Lisp culture, since the multi-paradigm nature of the language appeals to deductive thinkers. Obviously I have studied psychonautics and chaos magick in some depth, and I was particularly taken by the idea from these modern schools of mysticism, that belief is a tool, that can be wielded to consciously control your own mind, much like (but not exactly like) how a programmer controls a computer by writing software.

As for my own heavily transhumanist "system" of Neuro-Occultism, it's more of a philosophical framework---the basic premise is that all supposedly supernatural phenomena can be explained in terms of psychology, neuroscience, and the physical sciences; that only once you have ruled out the possibility that a supposedly supernatural experience is a purely psychological phenomenon can you begin to model a physical explanation; that the experience of supposedly supernatural phenomena are more interesting and powerful when examined in this light; and that even qualitative systems such as the human mind can be described quantitatively, by adapting research in quantum computer science and biological computation to the field of neuroscience. It's not so different from Cognitive Science, only it emphasizes that once you know that all belief systems are just _paradigms_ , that the human mind can support multiple, simultaneous, even contradictory paradigms, and that your fundamental being is in fact a quantitative system, you can really start to put your brain to work. The problem lies with the fact that the language of the unconscious mind is purely symbolic and associative; thus, a mystical language is necessitated by the structure of our minds---even though a rigorous, mathematical model would be preferable in terms of the scientific method. Lisp, metaphorically applied to the model of the mind, brings us most of the way there.

The _purpose_ of Neuro-Occultism is to develop such a rigorous, mathematical model of consciousness and being; and in so doing, deprecate itself. I see this as an essential aspect of the "technological singularity", both for the realization of emergent machine intelligence, and for the transfer of human consciousness to a computational system---because until such time as the human mind can be understood quantitatively, the singularity will remain science- fiction and fantasy. But then, even the idea of the singularity is a problem, a fundamental limitation of current consciousness that prevents us from seeing past the event horizon of this convergence of technology, biology, individual and social psychology; in order to both achieve the singularity and transcend it, we need to first transcend our own segmented and qualitative perception of self.

There's a lot more I'd like to say on the subject, but that would be a book of its own. Back on topic: I do realize that the heavy-handed mystical tone and Lisp proselytization currently present in the introductory text of LLTHW is useless cruft; I'm a passionate and excitable person by nature, but I recognize that it is holding back the work and interfering with Zed Shaw's methodology. Writing a book is an iterative process, and my effort has been focused on getting a complete scope in order to pump out solid, relevant exercises---so for the time being, I've simply marked the intro chapters as rejected/need-to-be-rewritten. I _really_ hope it won't take me a few more years to finish this book though!

<comment><USER3> Thanks for responding. To be clear, I don't object to the inclusion of the mysticism, I simply find it intriguing. Most surprising to me were not your beliefs, but that you had coined a term, "Neuro-Occultism," that is utterly ungooglable--the only results returned are your own writings. I spent some time reading your blog where you discussed at length your connections between mysticism and Lisp.

I was disappointed, though, to learn that your place of employment is not strictly Lisp-only.

...Now I feel like a total stalker. It's all a few clicks away from the LLTHW site, I swear!

<comment><USER4> Haha---it's fine. The internet makes everyone's life an open-book. Which place of employment do you mean, though? As a contractor, I jump around a lot; but I'm also involved with a start-up (but that's still running in stealth mode, so there's not much posted about it online). I have managed to use Common Lisp at nearly every contract or job I've worked at for the past few years though ---once employers and clients became more responsive to it again. Even when the job didn't strictly allow it, I used Lisp for code generation anyway.

As to your clarification---yes, that was understood. I was more speaking to the general criticisms about my tendency towards mystical language, since that comes up fairly often. I would be more surprised if there _was_ third-party material discussing Neuro-Occultism, TBH---the occult community at large dislikes it because I deny a metaphysical explanation; and most of the people in the scientific community that I've shown it to dislike it because it even deals with the problem of mysticism (much like Freud criticized the work of Carl Jung for the same reason). How dare I!

That being said, I have been making good progress this year on my adapted process calculus---I'm just putting the finishing touches on the BNF grammar, and then I can begin testing its logical consistency and writing proofs. Once it's finished, I'm hoping to be able to describe physics, quantized consciousness, quantum and classical computing all with the same notation. _Fingers crossed_.

</comment></comment></comment></comment></comment><comment><USER5> I really think the title for this should be changed. The title mimics zedshaw's "Learn X the Hard Way," (which, by the way, is fantastic), but the _content_ doesn't mimic any of the things that make "Learn X the Hard Way" great.

The brilliant thing about zedshaw's "Learn X The Hard Way" is that it focuses on typing the code and learn-by-doing programming. Learn Lisp the Hard Way just explains Lisp then tacks on a few exercises.

I (and presumably Zed, from his previous comments), wouldn't mind if the author had mimicked the entire format, because it works. "Learn Lisp the Hard Way" would be necessarily very different from "Learn JavaScript the Hard Way," but this is just a programming book with a familiar yet misleading title slapped on top.

<comment><USER4> You're right, of course. It's a little overwhelming at times, how much interest and attention this project has garnered---especially so early into the 2nd draft, where I'm still shaping the breadth, depth, scope, and direction of the content. The first time this project was posted to Hacker News earlier this year, I felt forced to push out exercises for the first two chapters as quickly as possible, just to give visitors some material to actually work with; but they do not yet reflect the final style and methodology that I'm aiming for. I do want to make it clear, though, that I'm not going to stop working on this project until it meets the standards set down by Zed Shaw for LxTHW-based books.

The most important factor, as I understand it, is the show-don't-tell method; it's also the most difficult to achieve for a language like Common Lisp, which is so foreign to most people. For the purposes of this draft-in-progress, however, just consider every explanation currently in the text as a placeholder for concrete examples that will illustrate the point better.

Another important factor is the pace of each exercise. One of the biggest features I noticed about Zed Shaw's Learn Code The Hard Way books is how perfectly he scaled the difficulty of progressive exercises, to maintain an even pace. For an absolute beginner to programming, an exercise should take no more than an hour to complete---and that's a goal I'm working towards for LLTHW as well.

To achieve these goals, once I finish laying out the content and direction with the intro text to each chapter, I'm going to be working backwards in each Part, writing progressively easier exercises, to make sure that all necessary material is covered, and that the pace is structured properly. But even once the 2nd draft is complete, I will still be relying on user feedback to adjust the ordering and pace of the material, as needed.

Thanks for your feedback, and I hope you'll continue participating in this project as I work out all the kinks!

</comment></comment><comment><USER6> The best lisp book I have found to learn Lisp, while really understanding all that's happening underneath is "COMMON LISP: An Interactive Approach".

Basically, there's no hand waving in this book. It doesn't teach you to have a lisp blog in five minutes doing copy paste of code you don't understand.

It respects you as a smart learner, and makes you write the code, you learn doing stuff by yourself being smartly led by the author, and by the end of the book you have written a very complex piece of software with many advanced concepts and you understand more about lisp than you could have by following endless web tutorials.

The book can be downloaded from: [http://www.cse.buffalo.edu/~shapiro/Commonlisp/](http://www.cse.buffalo.edu/~shapiro/Commonlisp/)

It is to me a vastly underrated resource for all people interested in Lisp.

<comment><USER4> Thanks for the link! I'm surprised that I have not seen this before.

The methodology in this book is definitely close to what I'm trying to achieve with LLTHW. I'll be sure to add it to the list of references, and look forward to what it can teach me about teaching Lisp.

</comment></comment><comment><USER4> Thanks everyone for your continued interest and support of this project as I work towards completing the second draft!

Unfortunately, it looks like the traffic spike has once again caused my webhost to kill and block the web application's process---so I'm going to have to move over to a better cloud service and an async web-app to better support this level of interest from the community.

I will announce the re-launch of LLTHW through my blog, which is syndicated on Planet Lisp. Until then, I do highly recommend Practical Common Lisp by Peter Seibel, also available online for free at: [http://www.gigamonkeys.com/book/](http://www.gigamonkeys.com/book/)

</comment><comment><USER7> > Lisp—the friendly nickname for Common Lisp

Sorry, but this is an awful way to start... just get the Wikipedia definition?

<comment> muuh-gnu Or dont talk about these prehistoric details _at all_.

Dont talk about the 80s. Dont talk about 27 different and incompatible implementations. Dont talk about lambda calculus or McCarthy. Dont talk about 1001 different editors. Nobody finding about Lisp today cares about these things, it is just annoying noise that dilutes the message.

If youre stealing the title of a Python book, then at least make the experience as newbie-friendly as Python is.

</comment></comment><comment><USER8> Just a quick note, even though it's been mentioned already: I let people and even encourage them to copy my method and use a similar title to me own Learn X The Hard Way. That is all.

</comment><comment><USER9> I found the Arc language tutorial to be a really easy to read and understand. It has renewed my interest in Clojure and I am glad I took the time to look through it.

[http://old.ycombinator.com/arc/tut.txt](http://old.ycombinator.com/arc/tut.txt)

</comment><comment><USER10> "Programming MotherFucker - Do you speak it?" -Zed Shaw

Couldn't resist the above quote from Zed Shaw; the guy who started the Learn X The Hard Way series. Overall I think these tend to be a very good approach to learn, especially for someone just starting out.

<comment><USER11> Zed didn't write this... it's some knockoff "hacker" using the same title and format.

<comment><USER12> Knock-offs are explicitly encouraged:

[https://gitorious.org/learn-x-the-hard-way/learn-x-the- hard-...](https://gitorious.org/learn-x-the-hard-way/learn-x-the-hard-way)

</comment></comment></comment><comment><USER13> I'm about to learn Lisp and/or Clojure(Script). How does this book differ from for e.g Land of Lisp? I was planning to get my fingers dirty with some more light material before digging in the recommendations (PAIP, PCL, SICP).

<comment><USER14> If you're interested in looking at Clojure, checkout Clojure for the Brave and True.

[http://www.braveclojure.com/](http://www.braveclojure.com/)

<comment><USER13> Thanks for the repleis! I'm currently close to web development (as people nowadays) so that's why I'm thinking about learning clojure/script rather than Lisp - because I can use clojure in daily work but not Lisp.

</comment></comment></comment><comment><USER15> That's a very expansive table of contents. I'm loving the site design and I look forward to the more difficult chapters, particularly the math-heavy ones. Good luck!

</comment><comment><USER16> This is awesome! Thanks so much! For general discussion: what are all the L<insert-language>THW sites? How do they compare (how far do you get, ease of use, etc)

</comment><comment><USER17> Direct link for the book in html [http://learnlispthehardway.org/book/](http://learnlispthehardway.org/book/)

</comment><comment><USER18> Thanks HN, the site is now throwing a 502. I didn't even make it into the second part of the preface. ;)

<comment><USER4> And it looks like my webhost is now automatically blocking the process. Sorry everyone!

</comment></comment><comment><USER19> The _really_ hard way. Bad Gateway.

</comment><comment><USER20> > Common Lisp is not a 'pure' functional language, however, such as Haskell; > it is multi-paradigm like OCaml. You can choose to use the functional > paradigm in Common Lisp if you like, but you can also use Procedural, > Object-Oriented, Event-Oriented, novel new paradigms like Aspect-Oriented, > or mix and match to your hearts content. __Strict Functional programming > languages do not offer this flexibility__.

"Strict functional programming languages" could be interpreted as languages with strict evaluation. But I guess it is clear in this context that they mean _pure_ functional languages (or pretty rigorous with regards to purity).</comment>


Belgium denounces loot boxes as gambling - <AUTHOR> https://arstechnica.co.uk/gaming/2017/11/belgium-denounces-loot-boxes-as-gambling-hawaiian-legislator-calls-them-predatory/ <comment><USER2> This should apply to physical goods such as blind bags, mystery boxes, baseball cards...</comment>


Ask HN: Default h5 and h6 fonts are smaller than normal text in HTML/CSS – why? - <AUTHOR> Maybe HN can help solve this little mystery. The default font sizes in HTML have, since at least 1998 [1], been .83em and .67em for h5 and h6, respectively, making them smaller than normal text by default (1em). This leads to the bizarre situation that without any styling, the h5 and h6 headings are smaller than the text they head!<p>Does anyone know why headings were made smaller than normal text? I bet the answer is buried in some mailing list from the mid 90s, but so far my searches have not been fruitful. Perhaps someone here was around at the time of, or was even involved in, this decision.<p>[1] https://stackoverflow.com/a/55711457/2251982 <comment><USER2> I'd imagine h5 and h6 were supposed to be used as headings for <small> text. Essentially things like legal text, footnotes, etc.

</comment><comment><USER3> I can't say for certain but I think it has something to do with the old HTML font tag. It supported a "size" attribute between 1 and 7. 3 was the default so I _think_ H5 and H6 might have corresponded to font tag sizes 1 and 2.</comment>


Introducing "Projects": cohesive collections of tracked pomodoros - <AUTHOR>

Tomatoes is a pomodoro timer and time tracker.
IMO one of the best Tomatoes' features is its low approximation of real work tracked time by design. Tomatoes tracks only real working time through pomodoros (pomodoros are time tracking quantums for the Pomodoro Technique®), so it could be used to estimate and compare work time effectively.
Each "tomato" has tags, I always used this feature to group tomatoes by project. When I work for "projec A" the first tag of every tomato is "project A".
Following this logic I created Projects to group tomatoes by tags and get access to project specific statistics.
You can try Projects by signing in and creating a new project at http://tomato.es/projects/new. Now start a new tomato and tag it with one of the project's tags, it should compare in project statistics. <comment><USER2> Neat - I've been using <http://pomodorocrate.com> for this, but I'll give this one a try. I like the github sign in option.

Do you have any plans for a badge/widget thing that I can put on my blog ("X has done Y pomodoros this week"-type of thing)?

<comment><AUTHOR> I tryed it too, it's a good product but I like most Tomatoes because I built it aiming for simplicity.

With Tomatoes you can press spacebar from the public index (<http://tomato.es>) to start the pomodoro timer, if you want to save progress you must sign up. I like services who let you try their product before you sign up.

Sign up with one-click auth process (through GitHub or Twitter) and press spacebar to start a new timer. At the end of the timer the only information needed to save a tomato is: none, just press enter. If you fill it with tags then you'll get access to advanced statistics through projects.

I'd like to introduce new users to Tomatoes gradually that's why I'm trying to setup a process of badges/grants to let advanced users access more features. Example: you can change timer progress bar color only after 100 tracked tomatoes.

The badge/widget/html plugin is on my TODO list: <https://github.com/potomak/tomatoes/issues/41>, follow the issue to get updated about development progress.</comment></comment>


Show HN: Jess: A Serverless and GUI-less app experiment - <AUTHOR> http://markwatsonatx.github.io/tutorial/openwhisk/serverless/2016/08/04/serverless-guiless-openwhisk.html <comment><AUTHOR> Full disclosure: I am an IBM employee and this project was built using IBM services. This was a personal project that I built for fun, but I think is pretty neat and the HN community may find interesting.</comment>


Aussie telco sends user data to US to build web filter - <AUTHOR> http://www.scmagazine.com.au/News/306441,telstra-tracks-users-to-build-web-filter.aspx

<comment><USER2> Amazing, I'm quite surprised this hasn't been picked up by larger media outlets.

Whilst there's nothing wrong with a 3rd party service accessing a publicly available web-site; for my ISP to _willingly_ on-sell my web access history to a 3rd party service managed outside Australia could well be illegal.

I hope Telstra doesn't just get let off the hook for this.

</comment><comment><USER3> When I heard Telstra, I thought - yeah that sounds about right. A truly disgusting monopolist.

<comment><USER4> It's amazing that Telstra can still surprise me with their business practices.

For those outside of Australia, Telstra have a reputation somewhere between GoDaddy and Facebook. They came to power as a legal monopoly, originally government run, and own the majority of all copper lines in Australia. Telstra was then privatised in three different stages and proceeded to bully the industry.

For years the highest speed ADSL1 connection you could receive was 1.5 Mbit/s due to Telstra artificially limiting all companies who used their copper lines. Only in the last half decade have they extended this to the normal 8 Mbit/s[1].

The idea that the data sent over to the US was "completely anonymised" is laughable. Far more technically competent companies, like Netflix[2], have made mistakes in their anonymisation procedures in the past -- I fail to see how Telstra could avoid such a fate. If the data were ever released, it'd likely end up more like the AOL incident[3].

[1]: [http://www.itwire.com/your-it- news/entertainment/7027-austra...](http://www.itwire.com/your-it- news/entertainment/7027-australia-breaks-through-15mbps-barrier-telstra- launches-adsl-2)

[2]: <http://en.wikipedia.org/wiki/Netflix_Prize#Privacy_concerns>

[3]: <http://en.wikipedia.org/wiki/AOL_search_data_leak>

</comment></comment><comment><USER5> As a Telstra customer I'm kind of pissed off about this. I'll be contacting my account rep to see what they have to say about it.

</comment><comment><USER6> Discussion here: [http://forums.whirlpool.net.au/forum- replies.cfm?t=1935438&#...</a>

</comment><comment><USER7> Despite all the criticism of the company, most who care about decent mobile internet are using them because no other network comes close.

</comment><comment><USER8> Another reason to use https, (and to deny telcos the right to run root certs)

<comment><USER9> The ISP can still track what domain you're going to if you use https.</comment></comment>


Apt-Get for Windows – OneGet and Chocolatey on Windows 10 - <AUTHOR> http://www.hanselman.com/blog/AptGetForWindowsOneGetAndChocolateyOnWindows10.aspx

<comment> norea-armozel I love the fact oneget has a chocolatey provider for it. But I'm still sticking with basic chocolatey powershell for the moment (I do use the GUI for it from time to time). It just seems odd it's taken this long for anyone to build such a repository for Windows. Maybe with the Windows Store and Chocolatey we'll see more QA on the apps curated in each respectively (fingers crossed).</comment>


Thoughts on Mitch Kapor vs. Mark Zuckerberg at Startup School - <AUTHOR> http://photomatt.net/2007/03/24/kapor-vs-zuckerberg/ <comment><USER2> As a greybeard in the making (36), my instinct is to dismiss comments like Mark's as inexperience and naivety. Those sorts of attitudes make me uncomfortable and edgy.

After some reflection, I'm forced to conclude that although such ageism is annoying, is naive, is arrogant, it's also beautiful. It is exactly that arrogance, the sure knowledge that the "establishment" is full of it and needs to be rescued by youth, that _has_ rescued us, many times. Its from that arrogance that the energy to drive change comes.

There are many examples. A mantra of the 60s was to never trust anyone over 30. Kurt Cobain didn't exactly work with a lot of elder statesmen of the music world. Bertold Brecht spent his 20s in active rejection of all drama that had come before. And the art world is chock full of young artists declaring that a new age had arrived -- Basquiat probably never even talked to anyone under 30, except Andy Warhol, who was at least pretending to be a teenager.

None of which makes Mark's words easier for me to hear, but I can't bring myself to dismiss the attitude. It's fuel for radical new ideas. It's the nuclear reactor of society.

<comment><USER3> A much more noble attitude than plugging your ears and humming -- which is how many people seem to react to this harsh reality.

The fact is that Kapor himself was very young when he made his mark. There are far more similarities between him and Zuckerberg than differences, regardless of their _opinions_.

<comment><USER4> You're confusing selection for objectivity. Startups founded by "hot wiz kids" get more media attention to the fact that they are young. Companies founded by older people do not have that hook, so there is less emphasis in their age when the media writes them up.

</comment></comment></comment><comment><USER5> Facebook is a product. Lotus is a business.

Facebook doesn't need to keep innovating and re-imagining itself. It's designed to do one thing and it already does that quite well. All Zuckerberg needs to do to continue milking his cash cow is to keep the product fresh and trendy. This means hiring the kind of young and trendy people who his product targets.

Lotus, on the other hand, is a business. And as such they need to constantly innovate to survive. That means finding new problems in new markets and delivering new products to new people. As such they need all the diversity they can get.

If Facebook wants to become a business, they'll need diversity too. If they're content to keep milking the cash cow they already have, I'd say Zuckerberg's strategy is sound.

</comment><comment><USER6> While it's interesting to think about what would be ideal in the abstract, I think any company that puts hiring someone who fits a demographic (ie, "young") over hiring the right person for the job is doing themselves a disservice. We all know woefully boring 25-year-olds and exciting, bleeding- edge 50-somethings, I'm sure.

That said, teens and 20-somethings tend to have much more time and energy on their hands -- and a tendency not to be stuck in old ruts. But I imagine they're also much more chaotic and restless. And simply inexperienced. Which could be problematic.

</comment><comment><USER7> What a stupid argument to be honest. Arguments such as this always get a laughter out of me.

Why does it have to be one way or the other? It is quite understandable that FB has a leaning for the young as much of FB feeds off of young folks. I can't imagine too many 50+ guys brainstorming next generation of FB features. At the same time I can't imagine too many grades in early 20s coming up with next set of Lotus features.

May be the whole thing was missing a big disclaimer: USE WHAT WORKS BEST FOR YOU:)

-Zaid

<comment><USER8> aka "limited life experience + overgeneralization = advice"

<comment><USER9> I was _just_ about to post that...

</comment></comment></comment><comment><AUTHOR> I agree with this guy. Mitch's talk was well put together and thoughtful. I think building a diverse team (assuming everybody is highly capable of course) wins most of the time.

<comment><USER3> _"I think building a diverse team (assuming everybody is highly capable of course) wins most of the time."_

We know diversity over the long-term is safer. Perhaps in startups, where the timespan is short, specialization and myopic vision win out?

Where do you see examples of diverse startups being successful? From what I see most are made up of young male geeks who could be brothers.

<comment><USER10> Good point. But companies should be built to last, not built to flip. If the corporate culture becomes "don't hire anyone over 30," will it be possible to change in a few years when you're no longer a startup?

</comment></comment></comment><comment><USER11> Mitch's talk was one of the ones I got the most out of. He seems like an all- round great guy - I have no doubt it'd be a hugely enjoyable experience to work with him.

</comment><comment><USER8> I think what Mark is trying to avoid is the "Curse of Knowledge" (To borrow the Heath brothers phrase - check out Made to Stick, great book) Facebook is all about innovation, I think they purposefully avoid old ideas. (preferring young people = fresh ideas) Thats not to say they aren't young experienced smart people.

<comment><USER12> "Facebook is all about innovation, I think they purposefully avoid old ideas."

Are they, really?

The only new idea I've seen come out of FaceBook is tagging photos by drawing boxes around the people. Other than that, they're your basic database-backed social networking app. There's very little new there: LiveJournal/Flickr/Friendster/MySpace did it all before.

Google innovates. Thinkature innovates. Justin.tv (much as I think their community is heading for disaster) innovates. FaceBook seems to have positioning going for them, but they do fairly little technical stuff that can't be done by a hobbyist programmer in college. Which seems to be what most of their hires are...

<comment><USER8> I think thats overgeneralizing a little, many of the problems they are solving on the back end are not simple, give them a little credit for scaling from nothing to the 6th biggest website in the US very smoothly.

All the people I know that work there are far from "hobbyist programmers" and they are all damn smart, a fair amount have owned and sold companies before working there.

The innovation that comes out of Facebook is not purely technological, but more idealistic. They took stuff that had been done before and uniquely applied in a way that hadn't done before, doesn't that pass as a definition of innovation?

</comment></comment></comment><comment><USER4> In my hiring, there is one thing that is paramount over all- attitude. And generally the attitude that gets people filtered out is arrogance. Not confidence, but arrogance.

Discriminating on age is silly. As is technological proficiency for non- technical positions (to a point.) I'll take a killer sales guy who's just getting by technologically over one who has accepted patches in the linux kernel but doesn't have the drive.

Too many people of one age fail to value people of a different age group... give me two equally proficient engineers, one with 20 years experience and one with 2 years experience, and I'll try to hire them both. But if either of them is arrogant, I'm not interested.

</comment><comment><USER13> "If you want to found a successful company, you should only hire young people"

"Next challenge is to make the world understand that Facebook isn't just a college thing"

Anybody else see a cause-and-effect relationship between the above quotes?

</comment><comment><USER14> I knew Mark's would be drawing some fast criticism. There were some things he said that raised my eyebrows, sure. Super arrogant, absolutely. I sure as hell got something out of it though. He just gets what he's doing. He sees how critical it is to keep technical people behind the company. And while his blanket statement about youthfulness made some eyes roll, it holds true for most of us and especially facebook. No matter what you might think of the guy, it'd be a really good idea to buy facebook stock when they eventually go public.</comment>


A Study of Linux File System Evolution (2013) [pdf] - <AUTHOR> https://www.usenix.org/system/files/login/articles/03_lu_010-017_final.pdf <comment><USER2> "Bugs are prevalent in both young and mature file systems."

"Over time, the number of bugs does not diminish, but rather remains a constant in a file system's lifetime."

"We observed that similar mistakes recur, both within a single file system and across different file systems. "

Essentially a completely different approach to file system development is necessary to produce something more reliable. But there is no market for it and no right people to do it. And I have doubts such people can even exist, because it requires both understanding reliability well enough to have a decent approach, but not well enough to be blind to many risks and think pursuing such project is even a good idea. So kernel file systems are sort of always written by people who should not be writing file systems.

Anyway, relying on the lower layer was never a good idea to begin with.

<comment><USER3> The trick to producing high quality software is always incremental development. You can't build something huge all at once, by the time you find out what your mistakes were you've already got too much complexity and crap built around them to really fix them.

You have to start out small, get something minimal and basic not just working but robust enough that you understand it, rewriting it as many times as it takes to get it right. Then you add the next feature or enhancement, and then the next, all the while rewriting shit when you discover your understanding some part of the system was flawed.

The reason filesystems are hard is because they're hard to develop incrementally - you need a huge number of different moving parts before you have a real filesystem. And no one wants a toy filesystem, there's huge pressure to get something really sophisticated done quickly because anything less is going to be uninteresting compared to what we have now.

That's really most of it, if you want to produce high quality code you have to resist the urge to go too quickly and you have to go back and fix your mistakes as soon as you find them, even when it's not very fun.

<comment><USER4> I think "rewriting shit" may be one of the leading causes of recurring bugs...</comment></comment></comment>


Rant: Open-source signal app re-released in India as 'WhatsIN' - <AUTHOR> https://play.google.com/store/apps/details?id=com.WhatsIN <comment><USER2> Report as "Copycat" from play store

</comment><comment><USER3> this is just shameful

<comment><USER3> i wonder if this is even legally allowed</comment></comment>


Show HN: Wasienv – WebAssembly WASI Development Toolchain for C/C++ - <AUTHOR> https://medium.com/wasmer/wasienv-wasi-development-workflow-for-humans-1811d9a50345 <comment><USER2> I see that you're running this as a for-profit company. How do you plan to monetize it?

<comment><AUTHOR> Wasienv was created with the intention of becoming a multi-org project (even if was stared by Wasmer).

As a side note, we don't plan to monetize the projects that we open-sourced. We plan to create tools that are only needed for enterprises when running WebAssembly server-side, and will be those tools the ones that will eventually generate revenue.

Hope this clarifies the question!</comment></comment>


Show HN: Poetry Every Day – Poetry as a Service - <AUTHOR> https://poetryeveryday.com <comment><USER2> I liked how focused and simple this is.

It may look better if some sentences didn't break to a second line.

I wish I could pay per month. For me it's the principle, I want to try before I commit.

> "Poetry Every Day has the ability to keep track of which poem emails are > opened."

Since you can't control how I read email, how does this work? Do I visit a web page to read the poem, or do I read it from my inbox?

<comment><AUTHOR> Great points. Thanks for the feedback.

I ended up deciding on yearly pricing to keep processing costs down. Each charge is .30 + 2.9%, so it's cheaper for me if I only charge once a year. Monthly pricing is something I'm going to have to really consider. Or maybe a free month to get started. Thanks for the perspective.

My email provider (Mandrill) allows you to choose whether you want to track opens on each email you send. I'm guessing they use some sort of tracking pixel. So you still get the poems in your inbox, but they watch their servers for if that pixel was requested.

</comment></comment><comment><USER3> Not taking my $10/yr. [https://www.poets.org/poetsorg/poem- day](https://www.poets.org/poetsorg/poem-day)

<comment><AUTHOR> Thanks for the feedback!

After I started building Poetry Every Day, I ran across that very site. I continued building because I think they attract a different type of reader than I am envisioning would be interested in Poetry Every Day. The focus of Poetry Every Day is providing poetry that has stood the test of time. The focus of the American Academy of Poets is to showcase its (living) members' work, interspersed with some classic poetry. That's not at all a bad thing, but I think there are people who are interested in classic poetry that are not interested in contemporary poetry. Those are the people I created Poetry Every Day for.</comment></comment>


A Beginner's Guide to iOS Provisioning Profiles - <AUTHOR> http://www.theodo.fr/blog/2017/02/a-beginners-guide-to-ios-provisioning-profiles/ <comment><USER2> The tooling around iOS is a mess. Provisioning profiles, entitlements, plists, signing identities, APN certificates, keychains, targets, frameworks, service extensions are pretty much impenetrable. None of it makes sense conceptually and everything is vastly overcomplicated, so you're essentially following a wizard in XCode (the infamous "Fix problems" dialog), copy and pasting answers to desperate Stack Overflow questions or simply randomly trying things until it works.

XCode is the worst. Many pieces of functionality are only exposed through XCode rather than via a command line API. This means that you're essentially tied to a UI, Visual Basic style; building artifacts on a headless CI server requires you to jump through all kinds of hoops like unlocking a keychain. Worst of all, XCode itself is buggy more often than it is not, leading to the common advice to "close XCode and delete your Derived Data directory".

You're stuck between manually modifying the (eminently non-human-readable) project files in an editor, in which case you can see what you're changing, or going through a ever-changing UI, risking accidental breakage. From the perspective of a Unix developer, it's a wonder anyone gets anything done on iOS.

<comment><USER3> I am _pretty certain_ you can accomplish anything Xcode can do using a combination of the openssl command line tool, Apple's codesign command line tool, and manually flipping switches on Apple's website (which is only needed to set things up, not build stuff later); but, to be honest, I am normally (but I don't think usually...) using some of my custom tooling, which means I am not 100% sure (I am the developer of Cydia Impactor, which reimplements and automates all of this stuff to accomplish "here is an IPA that may or may not be signed; I want to install this on my iOS device as if it were signed by me" on any platform, such as Windows or Linux). Do you have an example of something that you believe can only be done by Xcode? I get the impression that a lot of iOS developers just kind of assume they are locked into Xcode, but in fact I want to argue no one should be using Xcode (as it really does suck, and it is totally unneeded).

FWIW, I _don 't_ know how to use the codesign utility without unlocking the keychain, but that UI has nothing to do with Xcode, and I bet someone who is an expert with the keychain might have a non-crazy workaround for you given that I think the codesign application lets you specify a custom keychain: like, I would be surprised it you can't make a keychain that doesn't require being unlocked. To me, the most annoying thing about the official tooling is that the codesign tool uses Apple's "timestamp server" (AFAIK, in order to help make things not do devastating if you have to revoke a private key: you can use the embedded signed timestamp to trust that a binary was signed before it was revoked) and so does not work unless you have a connection to the Internet.

</comment></comment><comment><USER4> My company manages just a couple apps for iOS. They aren't updated too frequently, maybe 3ish times per year. Few things fill me with dread more than trying to release a new iOS app after a certificate has expired. As others have mentioned, the process around provisioning profiles, certificates, managing them within Xcode, etc, is extremely complicated, and the 2-5 day review period makes things even more stressful because there's no easy way to just upload a fix when something goes wrong (like device tokens suddenly stop generating in production). Since we push updates so infrequently, every other push requires updated certificates and the large time gaps make it easy to forget how much of a pain it is until you're trying to do it.

Some things that I am thankful for:

\- TestFlight. It's a pain that I have to have the app approved before I can send the beta out to my internal users. Seems like internal should let internal users update to a beta version without review (while external would still require a review). At least it lets us test with our production certificates eventually. It's still a pain if something is discovered and it requires a rebuild and a new review.

\- Emergency Review Requests. I've had to submit 3 of these over the past several years, and Apple has always initiated my within 2 hours. I _really_ appreciate this, and I'm glad that people haven't abused it so much that they've scrapped it.

<comment><USER3> Is there a service or GUI tool which, if it magically existed and understood all of these steps and so was only limited by the underlying cryptography involved, would noticeably mitigate or even dissipate your "dread"?

<comment><USER4> There's [https://fastlane.tools](https://fastlane.tools), but I haven't looked into it a ton. It seems to require a big investment to get things rolling, but probably solves a lot of these problems after that. I'll have to revisit it at some point...

<comment><USER3> I am more trying to ask the question "what is the minimal modification to your current, depressing workflow that would have made your life easier: what is the magic artifact weapon you wish you had in your arsenal to cut through your pain points (or even just, what is your single largest obstacle in the middle of the battle, when boiled down to a single moment where a deux ex machina would have been useful)", as opposed to "would you be willing to opt into a totally different lifestyle of peace and love, it only requires that you disavow all of your current earthly possessions and relationships".

</comment></comment></comment></comment><comment><USER3> > I once even got sent a 40-character, hexadecimal string that wasn't a valid > UDID, and looked nothing like the actual one they eventually sent me. To > this day, I still have no idea where they got it from.

A UDID is the result of a SHA-1 calculation: there is no such thing as a 40-character hexadecimal string which is "isn't a valid UDID" by syntax, so this is interesting to me: if the author ever sees this, did you get an error saying that from Apple (in which case we know they have a massive database of every device in existence)?

(Note that UDIDs beginning with 32-bits of F are returned by the APIs that provide app-specific advertising identifiers on the device, so if you saw one of those and decided it was "invalid", that was returned because they used a tool which tried to return a UDID but was using the older public APIs to do that from a sandboxed application.)

(edit: Oh, I just noticed there are comments on the website. I'm stupid, and will copy this there.)

<comment><USER5> > if the author ever sees this, did you get an error saying that from Apple > (in which case we know they have a massive database of every device in > existence)

Some sort of data is bundled up in that string: when you add a device's UDID to the Apple dev portal, the confirmation page will tell you what type of device it is (iPad 2, iPhone 7, etc).

I can't recall entering a bad UDID, so I'm unsure what that looks like.

<comment><USER3> I can tell you with 100% certainty that a UDID is the result of a SHA-1 and so there is no ability to have "data bundled up in that string"; I know this because we've reverse engineered the computation of this string, and there is now tons of software in the wild which just builds it from parts instead of using Apple's APIs. Here's information on the algorithm from our Wiki.

[https://www.theiphonewiki.com/wiki/UDID](https://www.theiphonewiki.com/wiki/UDID)

For Apple to be telling you what kind of device it is, they either have to have a database of all the devices as they are built or a database of devices which have been checking in to their servers. (I'm betting the latter is what is happening here, but the former would be fundamentally more interesting to me.)

<comment><AUTHOR> Hello! Yes, as orbitur mentioned, Apple tells you the device type after you enter a UDID. The one that didn't work _was_ accepted, but didn't return a device type. We tried it anyway, but the app wouldn't install, which is why I described it as 'invalid'.

> Note that UDIDs beginning with 32-bits of F are returned by the APIs that > provide app-specific advertising identifiers on the device, so if you saw > one of those and decided it was "invalid", that was returned because they > used a tool which tried to return a UDID but was using the older public APIs > to do that from a sandboxed application

It did have a bunch of Fs at the beginning, so that is probably the explanation! Thanks :)

</comment></comment></comment></comment><comment><USER6> Everything to do with iOS development and deployment is just so mindbogglingly complicated.

I dread everytime I'm forced to open XCode to compile or deploy something.

<comment><USER7> I have felt this pain also. I had a play - even spent a bit on the developer ID. What a waste. I was doing a Unity 3D* app for fun (part of the fun would be publishing it) and got all the way to the end, just to realise the amount of bureaucracy and hoops to jump through to publish, just isn't worth it. I want to write and publish software not be a source for the app store inventory sink. Instead, I will write software on a different platform all together. Apple's loss, not mine.

* Unity 3D applications are deployed to an iOS device through XCode.

</comment></comment><comment><USER8> As someone interested in moving slowly into mobile development from heavy web application development experience, is Android development much easier?

<comment><USER9> The provisioning? Yes, easier on Android. Getting published in the app store? Yes. Having an IDE that doesn't crash daily? Yes.

Everything else is harder/worse though. Documentation, SDK/APIs, device ecosystem (so, testing and QA). So pick which part(s) of the experience you'd rather have not-suck and go with the platform that matches it best, if ease of development is your main concern.

[EDIT] if you do decide to go with Android, look at Square's libraries and their documentation of how they develop for Android. They've done _a lot_ to de-shitify the platform, but it means doing things very differently from how you would if you followed the official docs. If you're doing anything non- trivial you could do a lot worse than deferring to Square's judgement on how to structure your application.</comment></comment>


The Case for Eating Jellyfish - <AUTHOR> https://horizon-magazine.eu/article/jellyfish-researchers-want-you-start-thinking-about-these-creatures-your-next-meal.html# <comment><USER3> Jellyfish salad is in fact a common Korean side dish.

[https://www.google.com/search?q=%ED%95%B4%ED%8C%8C%EB%A6%AC%...](https://www.google.com/search?q=%ED%95%B4%ED%8C%8C%EB%A6%AC%EB%83%89%EC%B1%84&tbm=isch)

<comment><USER4> It's eaten all over the Far East: [https://en.wikipedia.org/wiki/Jellyfish_as_food](https://en.wikipedia.org/wiki/Jellyfish_as_food)

</comment></comment><comment><USER5> Yeah. Chinese people have been eating jellyfish for a while now. It's pretty crunch.

<comment><USER6> Agreed. It can be found easily in markets in my hometown (just off the coast, east of China). And it's my favorite dish. Our style is just cutting them into noodles and make it salad. [https://www.google.com/search?q=%E5%87%89%E6%8B%8C%E9%B2%9C%...](https://www.google.com/search?q=%E5%87%89%E6%8B%8C%E9%B2%9C%E6%B5%B7%E8%9C%87&tbm=isch&ved=2ahUKEwjH873-w5XjAhWP1p8KHQ8mDW0Q2-cCegQIABAC&oq=%E5%87%89%E6%8B%8C%E9%B2%9C%E6%B5%B7%E8%9C%87&gs_l=mobile- gws-wiz- img.3...10146.10146..10620...0.0..0.81.81.1......0....1.W5M0k8b4izk&ei=bO8aXceNF4-t_wSPzLToBg&bih=658&biw=393&client=ms- android-google&prmd=ivn)

</comment></comment><comment><USER7> Can't we just feed it to pigs, and then eat the pigs?

<comment> King-Aaron I like the cut of your jib

</comment></comment><comment><USER8> I've eaten jellyfish as a small side dish a few times. The texture - <USER2> chewy, with a crunch of chewiness at the end of the bite - was bizarre the first time, but I got used to it quickly enough. I wouldn't mind eating a dish made with it, but it might benefit from a longer, slower cooking process. Or maybe jellyfish is nothing like mammal meat and it wouldn't help, I dunno.

<comment><USER9> Have you tried any of the "tree ear" type fungi? They have a chewy+crunchy texture and bland flavor too, and I wonder if it's similar.

<comment><USER10> We call those fungi, "tree jellyfish" in Japan :)

</comment></comment></comment><comment><USER11> >and the UV radiation from the sun should have killed any bacteria

[citation needed]

I've seen plenty of dead things still rot in the sun.

</comment><comment><USER12> Kerala, southern (almost) tip of west coast of India had jellyfish and puffer outbreaks threatening other catch. Anybody can tell if we can have a booming jellyfish business here?

</comment><comment><USER13> When life gives you jellyfish...

</comment><comment><USER14> Reality is lots of people do eat it of course and it's kinda boring. Interesting but not a real unique texture, not a lot of flavour.

For a meat it'll never take of, it's to bland. Kinda like pasta, but it's an animal so not as practical.

As a source of materials, perhaps...

</comment><comment><USER15> Url changed from [http://nautil.us//blog/the-case-for-eating- jellyfish](http://nautil.us//blog/the-case-for-eating-jellyfish), which points to this.</comment>


Writing and maintaining enterprise software with React - <AUTHOR> https://medium.com/@Extia/writing-and-maintaining-enterprise-software-with-react-c2fac282f385 <comment> crooked-v "Webpack hell" is why I've been a strong proponent of using react-app-wired to piggyback off all the work that goes into create-react-app.

Some of that complexity may go away with CRA 2, since Babel 7 macros can cover a hefty amount of stuff that's only possible with Webpack or another preprocessor today - including file loading.

Though, then there's the problem of everything tilting towards the entire dependency tree happening in Babel, and having a bajillion Babel macros instead of a bajillion Webpack config entries...

<comment><AUTHOR> Yes, might be the case. We went for next.js, I feel that right now, you should not really write your own babel/webpack config, it's probably simpler to go for an existing framework and accept its limitations, that go full custom. It makes things complicated. Yes, not using your favourite router/your css processor is sad, but I start to think that they're not worth it. And the frameworks are moving to be more customisable.</comment></comment>


Ask HN: working with a "bad" programmer - <AUTHOR>

I'm working at a startup with another programmer, the founders are business guys and they don't even look at the code.
The problem is that the other programmer have bad communication(we both work at home) and programming practices: a lot of files without comments, hard to understand/read code, buggy code, un-pythonic code... It's getting difficult to be productive in this environment.
What would you do in this situation? <comment><USER2> Daily code reviews worked for me. My colleague wasn't "bad" and I'm not great, but we had very different approaches to writing code that made collaboration difficult. Daily code reviews helped us get on the same page on a lot of things and also allowed me to casually introduce new programming concepts or provide feedback on questionable programming practices.

</comment><comment><USER3> Be straight with him. That you both need to work on your communication back and forth and you'd like it if he could use more comments in his code. Tell him the time writing a comment saves you ten-fold on stopping to 'follow the program'. Ask him if he's been having trouble with any of your comments. (Communication takes two people, errors happen between BOTH people.)

Coding practices, try and work on him with it...don't be direct but use a 'hey, I know a way you might like to do this instead, let me show you' type approach. It will take a lot of time to break bad-habits. I started programming not using Camel notation, instead preferring title case...I still prefer Title Case after _years_ of trying to break myself :)

</comment><comment><USER4> From my experience, there are two types of "bad" programmers: Those that want to improve and work with you, and those that don't, or at least not take advice from you.

For the first category, as others have said, you should try to mentor them.

For the second category, this was tough in my experience. I did my best trying to work on my communication, being friendly, but the other programmer just ignored it. After I gave it some time, I wrote the business guys (some have a technical background though) what problems I had with the other programmer. If you keep it high-level and that it is mainly the communication that doesn't work, they should get it.

From then on, it's really their job to fix the problem. In my case, it was handled pretty good. I didn't become best friends with the other programmer, but it was workable. If your management can't fix the problem (final escalation: firing the other guy), you should quit. This will not be the last time such problems will pop up in the company (be it engineering or another part) and good management is able to handle that.

</comment><comment><USER5> The first question is, since you are not a founder how are you being compensated?

The next is, does the code quality really effect your compensation over the long term?

Finally, productivity is not lines of code, but revenue and users. Good coding practice may make a slight difference in the success of a startup, but odds are it won't.

The key is determining if the likely pain is worth the potential outsized rewards. If the rewards are not potentially outsized, then it's not really a startup.

Good luck

</comment><comment><USER6> It depends on whether he's bad and doesn't think he's bad or he's bad and he doesn't know he's bad.

If it's the former, he could literally kill the startup.

If it's the latter, I can honestly say I have only met a few programmers who were incapable of learning good coding practices.

</comment><comment><USER7> If you don't have a problem getting work, then just leave and look for the next gig. Finding the right fit can be difficult, luckily these days developers have lots of choices.

</comment><comment><USER8> You haven't provided enough information to provide any useful advice. Care to elaborate?

<comment><USER9> One of the ways that control/power issues first manifest are complaints about style. We need specific examples to tell if there is a legitimate problem.

</comment></comment><comment><USER10> Code reviews and distributed pair programming (for Eclipse we use Saros plugin).

</comment><comment><USER11> Can you gauge how cooperative the other programmer will be in having a discussion about best practices? Hopefully he/she is at least decent with versioning. How about testing? Do you think the other programmer would be open to doing TDD? I know TDD isn't everyone's cup of tea, but it's certainly easier to get into than it is to teach someone how to write comments or change their style of coding.

</comment><comment><USER11> What's the question?

<comment><AUTHOR> I'm sorry, I had a problem with the submission.

</comment></comment><comment><USER12> Mentor him. "In this section of code, you can do this and it looks cleaner." It sounds like most of the problem is that he is short on experience and does not know how to be a good programmer, so be the best example of a good programmer and teammate that you can. Teach him a few things and he might look up to you and start picking up your habits.

Make sure he knows how to debug so that you can tell him about a bug in his software and he can fix it so you don't have to.</comment>


What automated testing tools do you use in your software development process? - <AUTHOR>

What automated testing tools do you use in your software development process? Do you use or know similar automated testing solution like roboqa.com? Or do you write your own Selenium script for testing? <comment><USER2> We have three layers of testing in our suite. Ill go from the bottom up (we happen to be a rails shop so use rspec + Capybara):

1\. Model Tests: These are used to validate base business logic. This is for things like totaling up order values, making sure discounts are applying correctly, and making sure taxes are being correctly applied. These in my opinion are the tests you _must_ have. If you're not validating your base business logic theres no way to prove your other testing suites are doing their job. These are done for both Ruby code (rspec) and Javascript code (using Jasmine)

2\. Controller/API Tests: These are to validate that different parts of the business logic working together actually do what is intended. When a user places an order lots of things must happen (I need to charge them, I need to send them an email, etc.). These are done in rspec and are a nice way of validating things in an orchestration style API (vs. a REST style API).

3\. Selenium/Acceptance Testing: These are super important. These actually automate what a real user is going to be doing on your site. We test both Admin and normal user flows. These are the easiest to write and give some of the biggest wins. These will catch bugs your users are actually going to encounter. Having model and controller tests for something like checkout are necessary but they _must_ be augmented with acceptance tests or else you can't be sure something else isn't holding up your user from checking out.

Our entire test suite runs on CircleCI (love those guys) but could technically be run on almost any platform (we ran Jenkins for a bit too). Hope this helps. Feel free to ask any questions!

<comment><AUTHOR> for the acceptance testing, how often do you run it? just curious. I found selenium to be unreliable and just stopped itself for no reason after running for a couple of hours.</comment></comment>


8192+ bit RSA keys in OS X - <AUTHOR> http://shizmob.tumblr.com/post/67305143330/8192-bit-rsa-keys-in-os-x <comment><USER2> 8192 bit RSA key is one or two notches above overkill. 2048 is expected to last many more decades, and I haven't seen 4096 outside tin-foil hat environments. I know our national root certification authority uses 4096, for example.

I propose such a key actually decreases security because it is less compatible with existing software, training the users to further ignore warnings or dangerously tinker with their security settings.

Which one is more likely? NSA being able to break 4096 keys, but not 8192, or your user accepting an invalid certificate because "the key is probably just too big", or "it drains too much battery"? Which one will have more impact down the line?

Besides, if you are worried about such sophisticated attackers, your priority should be securing side channels and protecting yourself from rubber-hose cryptanalysis ([http://en.wikipedia.org/wiki/Rubber- hose_cryptanalysis](http://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis)).

<comment><USER3> What is the relative cost in cpu/memory of encrypting with 8192 bit vs. 2048 bit RSA?

<comment><USER4> According to the article, it ranges from 16x more time-complex to 256x more time-complex, depending on what you're doing with it.

<comment><USER5> This is a good analysis as well: [http://security.stackexchange.com/questions/41937/pgp-rsa- ke...](http://security.stackexchange.com/questions/41937/pgp-rsa-key-size- encryption-decryption-time)

</comment></comment></comment></comment><comment><USER6> Is he going to have to tell everyone who uses these affected versions of OS X to run these commands / change these preferences in order to view his site? This is much worse than he expressly states... How many people are going to put in the effort to contact the site author, or investigate the error, instead of writing off the site entirely? My takeaway from this is not to update a machine to be able to view a site with large certificates, it is to not use large certificates until Apple releases a fix for this.

</comment><comment><USER7> For reference, this is how fast OpenSSL is with various key sizes on my Core i5, 2.6GHz:

                          sign    verify    sign/s verify/s
        rsa  512 bits 0.000192s 0.000014s   5209.8  72185.6
        rsa 1024 bits 0.000909s 0.000037s   1100.4  27318.3
        rsa 2048 bits 0.004911s 0.000109s    203.6   9180.2
        rsa 4096 bits 0.030147s 0.000413s     33.2   2419.1

<comment><USER8> Thanks for posting this. I've always wondered what the numbers were. 4096 bits does appear to add a significant work factor.

<comment><USER7> Extrapolating a bit, the numbers for 8kb keys should be about 5 sign/sec, 500 verify/sec.

</comment></comment></comment><comment><USER9> Note that iOS has the same issue, except there's no way to change the relevant setting (AFAIK), and in general 8k keys are likely to be prohibitively slow on mobile.

</comment><comment><USER10> Alternatively one could use Elliptic Curve Cryptography to mitigate potential DOS issues as it less computationally intensive. For example a 409 ECC key is equivalent to a 7680 RSA key. For more on this read "ECC Cipher Suites for TLS", RFC 4492. [http://www.ietf.org/rfc/rfc4492.txt](http://www.ietf.org/rfc/rfc4492.txt)

Be sure to take note of which curves to use as only some are supported by the TLS standard: [http://stackoverflow.com/questions/16334662/some-elliptic- cu...](http://stackoverflow.com/questions/16334662/some-elliptic-curves-in- openssl-give-no-shared-cipher-errors)

</comment><comment><USER11> So what's the actual limit it is set to by default? If I get a certificate, I'm not exactly going to tell everyone to run a sudo command before opening the site :)

<comment><USER12> 4096 according to the code linked to in the article - [http://opensource.apple.com/source/Security/Security-55471/l...](http://opensource.apple.com/source/Security/Security-55471/libsecurity_apple_csp/lib/RSA_DSA_keys.h)

<comment><USER13> I noticed the Certificate Assistant UI in Keychain Access only lets you choose as high as 2048 bits if you're generating certs that way.

</comment></comment></comment><comment><USER13> Too funny -- I just went through this same exercise to see what the limits were and figured nobody would actually care about it since > 2048 bits is a little bit crazy.

I also found that TLS1.2 is not supported in Mail.app on Mavericks, even though it is supported in Safari. I wanted to see if I could enable TLS1.2-only AES-GCM on everything and quickly found the SMTP/IMAP TLS support is lacking.

</comment><comment><USER14> Annoyingly, StartSSL doesn't support ECDSA (well say they are less than the required 1024 bits, which they are but are more secure comparably).

</comment><comment><USER15> Doesn´t it take 10^100 universes to crack 8192 bit RSA?

<comment><USER16> > Doesn´t it take 10^100 universes to crack 8192 bit RSA?

That's easy to test:

a = 2^8192 ≅ 1.09 * 10^2466 ([http://www.wolframalpha.com/input/?i=2%5E8192](http://www.wolframalpha.com/input/?i=2%5E8192))

b = 10^100 universes

If we assume one universe can only crack one value, then we need many more than 10^100 universes. But it's reasonable to assume that one universe can crack more than one encrypted value. Let's say that each universe can crack a million values. Then 10^100 universes is too many.</comment></comment>