The Risk of a Billion-Dollar Valuation in Silicon Valley - <AUTHOR> http://www.nytimes.com/2015/09/23/business/dealbook/the-risk-of-a-billion-dollar-valuation-in-silicon-valley.html?nlid=65508833&ref=dealbook <comment><USER2> The analysis in this article is very superficial.

Liquidation preferences do not drive up valuations. Of course, they offer "insurance" to preferred stock investors against downside risk. But they have being so for several decades in the Valley (and elsewhere) and this has nothing to do with valuations as such.

Indeed, when valuations are at their very lowest (such as post dot-bomb in the early 2000's), the liquidation preferences became so high as to be regarded as absurd (e.g., 3x or even higher). This was often coupled with the idea that the preferred stock would be participating, meaning that the investors in any M&A deal get their 1x (or 2x or 3x or whatever) back _and_ also get to take their proportionate share of the merger consideration on the M&A deal itself.

The reason there are $1B+ valuations is primarily because the VCs believe the ventures will come to dominate major areas of commerce, will typically go public with sky-high valuations, and will continue to grow and dominate even after all that. Investing $100M at $1B valuation is risky but pays hugely if the company later becomes valued at $100B+. Yet, when a company goes public, the terms of the preferred stock typically require conversion into common stock and, in that case, the liquidation preference goes away altogether and confers no benefit on the investor.

In short, very incorrect analysis and not really worth reading.

<comment><USER3> Are you saying you'd value shares at the same amount with or without a liquidation preference? I'd value the shares with liquidation preference at a premium, no contest.

e.g. 1,000 total shares. You can buy 10% (100 shares) for $10mm with 2x liquidation preference included.

Now say I remove the liquidation preference. Your valuation model doesn't change? Mine certainly does. I'd value the shares lower, causing a lower company valuation for the 10% of the company that's changing hands.

> _The reason there are $1B+ valuations is primarily because the VCs believe > the ventures will come to dominate major areas of commerce, will typically > go public with sky-high valuations, and will continue to grow and dominate > even after all that. Investing $100M at $1B valuation is risky but pays > hugely if the company later becomes valued at $100B+._

It pays hugely even in a down round with liquidation prefs. I'd invest $100mm at a $1bn valuation with 2x liquidation preference, even if I thought the monetization event would occur at a $300mm valuation (down -70%). I'd still get paid out $200mm for a +100% return. If I didnt have the liquidation preference, I would've lost -70%.

<comment><USER4> I was under the impression that anything other than a 1x liquidation preference is extremely founder-unfavorable and very rare. Am I mistaken? Are these unicorns wandering around with significant (2x, 3x) preferences attached to them?

Because otherwise, a 1x only says you get your principal back. Covers the VC's butt in a down round, but nothing crazy. To the extent it comes out of founders' hide, well, you took money and didn't manage to make it grow. (The effect on rank-and-file employee options is a little less defensible, though, since they have less control over total execution.)

<comment><USER3> I haven't seen any data on it, but that's my understanding as well. (>1x is rare in today's market). But the NYT article does mention Honest Co. with a 2x on $1.7bn valuation, so there's at least that anecdote.

<comment><USER3> Actually I have heard/read that it gets more common in very late stage (near- IPO) financing rounds as well. For example, when a company is expected to IPO in the next 12-18 months but needs some more cash runway, there are funds that specialize in providing this type of "bridge loan" financing, which often comes in the form of preferred stock with heavy liquidation prefs.

</comment></comment></comment></comment></comment><comment><USER5> As someone who is reasonably familiar with term sheets, I feel embarrassed that I never gave much thought to the moral hazard that liquidation-preference clauses create.

Viewed from the perspective of a founder, they are a serious annoyance. But from the perspective of the public at large, they are being exploited to engage in pseudo-fraud.

Right now, the world treats a company's 'valuation' as a reliable signal of information about how much investors actually believe the company is worth. That information is then integrated into heuristics that influence various people's decisions: Will a paper write about a startup? Will a reader pay attention? Will a recruit take the company seriously? A billion dollar valuation goes a long way in each circumstance.

The problem is that our collective intuitions are using an outdated algorithm for assessing value. In theory, VCs who invest at a given valuation are providing reliable information by putting their money where their mouth is. But in practice, liquidation preference means that the official valuations attached to their deals don't really reflect the limited risks they are taking on.

A VC who invests $10 million at $1 billion valuation may officially be signaling to the world that a company is valuable. But if he insists on a two- times liquidation preference, then he is really indicating that when the whole thing blows up he wants to make sure he can get the first $20 million.

Unfortunately, that information isn't broadcast the same way to outside decision makers. Even those of us who think that startups are grossly overvalued don't give enough thought to how illusory those valuations are to the very investors whose capital is fueling them.

I hope that will start to change.

<comment><USER6> That same VC is only getting 1% of the company if they value it at $1B pre- money - that's the flip side of a high valuation - the higher it is, the less ownership the VC gets.

<comment><USER5> True. The question is how much the VC thinks that accumulated advantage (in sociology, "the Mathew effect," according to which the rich get richer) means that an increased present valuation can increase the probability of future increases in value.

And if the VC thinks that the upside is big enough — e.g., the next Uber — then 1% equity could be worth a billion dollars in the foreseeable future.

The trick to black-swan farming is casting a big enough net. And liquidation- preference makes it possible to take more bets by significantly decreasing downside risk on each one.

Obviously, we are aren't dealing with a linear relationship. Once companies reach a certain valuation, the prospects for future growth are significantly reduced. But there may be an intermediate stage where the benefits to the company are significant enough that the VC's probable ROI increases by investing at a higher valuation.

A VC who really wants to game the system should make a large seed investment at a low valuation, and then make smaller investments in later rounds at intentionally inflated valuations.

</comment></comment></comment><comment><USER7> This article talks a lot about the effects of preferences on the founders, but doesn't mention the employees, who get an even worse deal because their upside wasn't that big to start with.

Maybe at some point founders will start to refuse deals involving preferences, even at the expense of valuation and/or amount raised, in order to be able to offer their employees a better deal (and thus attract better employees).

<comment><USER8> Liquidation preferences are a hugely important term that protects investors from being screwed over by founders. Without it, nothing stops an unethical founder from raising 800k at a 8M cap, and turning right around and letting the company get acqui-hired for 4M a month later, pocketing $3.6M and leaving the investors with half their money.

With a liquidation preference; investors get their money back, the founders take their $3.2M, and nobody walks away feeling screwed over.

[Note: this example works exactly the same if you multiply the numbers by 100.]

As an investor; I don't invest unless I have 1x liquidation preference and pro-rata rights. These terms are standard because they're fair and they're critical for protecting the investor.

<comment><USER9> > nothing stops an unethical founder from raising 800k at a 8M cap, and > turning right around and letting the company get acqui-hired for 4M a month > later, pocketing $3.6M and leaving the investors with half their money.

Except that they just exchanged a stake worth $7.2m and sold it for $3.2m. Founders with large stock options are _more_ incentivized than even investors to maximize valuation in the event of a sale.

I understand that you want to make a bet while minimizing risk, but if you're going to try and guarantee your money back then as a company I'm going to price that in by minimizing the upside.

Without liquidation preferences, you as an investor can negotiate more reasonable valuations (if you're setting a cap of $8m and the company is willing to take a $4m buyout, you've seriously mispriced the company.) That means more potential upside.

</comment></comment></comment><comment><USER10> The article makes it sound like a liquidation preference is some new phenomenon that explains the recent surge of ostensible $1B valuations. In fact this has been a standard deal term since the 90s.

<comment><USER11> Just because it existed in the past shouldn't discount it's effects in the present as evidenced in the side effects of medicines.

<comment><USER5> The fact that liquidation preference has been standard in term sheets for decades mean that its _advent_ cannot have caused the recent inflated valuations. But the way that VCs are _employing_ liquidation preference may have changed. For example, the liquidation-preference term may have increased in importance if IPOs are becoming less common relative to other liquidation events or if out-of-control valuations mean that liquidation-preference is a more important form of protection than it used to be.

<comment><USER11> I agree with you. My argument was against altogether discouting Liquidation Preference as a suspect in higher evaluation by stating its existence in '90s.

</comment></comment></comment></comment><comment><USER12> One of the reasons that you hear CEO's want a $B valuation is that it becomes "easier to attract top talent". I'm not sure that is valid. You want talent that believes in your mission. Not all $B valued companies have the same risk/reward scenario. It'd be helpful to have some metric of the capital efficiency a company has to get to the $B mark.

The one good side effect is that private investors are taking all of the risk. If there is an adjustment in valuations across the industry, it should not effect the public markets the way it did in 2000. It could however impact the LP market and the number/size of VC funds could go through another cycle.

<comment><USER13> Top talent wants a low valuation so that stock options can provide a big payout.

<comment><USER14> Once your become a $1B+ startup, your options for liquidity events reduce greatly. Fewer and fewer markets can buy your company. Often when a company has a high valuation, people think it's 'too late' to join the unicorn. If the company isn't profitable on some level yet either, it's even worse.

<comment><USER4> This is a good point. The converse is also true, though: high valuation means you have lots of dollar-valued equity to use to entice possible employees. And that scales with your valuation.

Fun fact, a friend was complaining to me about how hard it is to hire Android engineers, because he keeps getting outbid by Uber. He's at a public company, by the way, but couldn't match their pay packages (including ~$1m in stock options).

Yes, you won't necessarily see the same crazy run up in stock value as if you joined at the ground floor, and yes, you'll owe taxes on the nominal value of the option price, etc... but that's still a lot of money, and it's arguably de-risked relative to an A-series startup. (Then again, if the company you're looking at isn't profitable, maybe it's not de-risked... buyer/employee beware.)

<comment><USER14> Uber is a bit of a special case. It's basically the next potential facebook / google.

<comment><USER15> If you join Uber at this point, you're only getting RSUs, not equity. They're way too large to offer shares to any more employees without triggering SEC disclosure requirements.

<comment><USER14> TBH, RSUs are better if you cannot afford to early exercise. Otherwise you have the 90 day option expiry problem after leaving your job, unlike most RSUs. Options also get bad with AMT tax if you didn't early exercise either. RSUs stay with you even after you leave the company.

Oh well, you lose long term capital gains tax benefits, but most people do not have the money to even exercise their vested options, so they sell during IPO and have equivalent tax treatment as an RSU.

Some companies now have option expiry dates at 7 years, but those can be counted on one hand.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> _With liquidation preferences, you can offer the venture capitalist a $1 billion valuation with the pitch that the liquidation preference will protect the investor on the downside._

Other than a vanity metric, which the press will run with for a short time, is there any financial benefit to trying to game a $1 BN valuation? Doesn't seem like it would make any aspect of running the company easier or smoother and would make a merger/acquisition even less likely. Since there is no direct liquidity in it either (unlike stock), unless the founders took money off the table, the founder doesn't materially benefit any more than they would have otherwise.

It seems like if you need multiple preferences to get to a specific valuation (as the article alludes to) then the risk does not match the fundamentals of the company.

Maybe this is just beating a dead horse though about how companies are not being valued on fundamentals, though in that case which ones to use is itself a contentious debate.

<comment><USER17> PR, scare competition, generate deal heat, sell.

<comment><USER18> This is actually a pretty rare sequence of events.

</comment></comment></comment><comment><USER19> Is no one talking about how Jessica Alba is a founder at a 1.7 billion dollar start-up?!?!

<comment><USER20> Agreed, that is interesting. Here's a puff-piece interview, she says the right things and says them well: [http://www.inc.com/magazine/201411/lindsay- blakely/how-jessi...](http://www.inc.com/magazine/201411/lindsay-blakely/how- jessica-alba-proved-her-doubters-were-wrong.html?cid=sf01001)

</comment></comment><comment><USER21> I'd like to see a website where you can select from a list of companies, select a start date on a timeline, and select a role (founder, CTO, engineer, etc.), a salary and benefits (stock) package to see how you'd make out at different times on the timeline.

</comment><comment><USER22> "Some unicorns, like Honest Company, have terms that require minimum I.P.O. prices for the V.C. investors that they just won't be able to meet anytime soon. According to Fenwick & West, 19 percent of the unicorns in their survey had such minimum price protection."

As a total outsider, this is the first I've heard of this clause. Is this also a significant contributor to the much, much later IPOs? (I mean, in reality, not in theory. The theory is obvious: "yes", but the theory doesn't prove a particular significance.)

<comment><USER23> How they can guarantee a minimum IPO price? Isn't that decided by the market?

<comment><USER7> The market decides the price, but the company decides the timing. Any IPO is postponed until it is clear the minimum price can be obtained.

<comment><USER24> _" The market decides the price"_

Well, not quite the market... just the undertak... I mean underwriters. Which is not quite as open-markety a process as one might assume.

</comment></comment></comment></comment><comment><USER25> There was an article about liquidation preferences and the impact on employees (incl. CEO) a few years ago that every startup employee should read to properly evaluate the package they receive.

[http://www.businessinsider.com/how-liquidation- preferences-w...](http://www.businessinsider.com/how-liquidation-preferences- work-2014-3)

</comment><comment><USER26> It is a combination of liquidation preferences & far more money going into the private market as there are fewer "investable" options in the public market & asset allocation becomes broader (a trend I see continuing: [https://medium.com/@emad/asset-allocation-not-share- prices-w...](https://medium.com/@emad/asset-allocation-not-share-prices-will- drive-vc-funding-723c0591d77c))

This is why you see hedge funds, family offices etc playing the $100m+ round space as Andreesen Horowitz for example showed in their recent funding report.

This is different to prior instances as there was less money available in the private market at this stage as typically public markets were seen as the preferred venue

A final few reasons were a) higher interest rates at prior times which made convertible notes/bonds not as attractive versus an equity IPO round and b) IPOs provided liquidity events that you can emulate now

</comment><comment><USER27> This article to me is a perfect example of bias in the media. It takes something commonplace and reasonable and explains it in a way that makes it sound vaguely nefarious. Why ? Because many NYTimes readers already have a vague anti business bias, is the only explanation I can think of. Or is it just clickbait tactics ?

</comment><comment><USER28> I don't think there's that much to worry about. If a VC wants a liquidation preference, that's fine--they'll have to pay for it by giving me a better valuation (in other words, giving me money money more cheaply).

The market corrects for all of these kinds of things.

</comment><comment><USER29> Some of those "unicorns" are going to die. Way too many minor companies now have "billion dollar valuations". There's some company with a single-signon service with a "billion dollar" valuation. Uber had $470 million in operating losses on $415 million in revenue, according to figures in a bond prospectus reported by Bloomberg in June.[1]

[] [http://www.bloomberg.com/news/articles/2015-06-30/uber- bonds...](http://www.bloomberg.com/news/articles/2015-06-30/uber-bonds-term- sheet-reveals-470-million-in-operating-losses)

<comment><USER30> That was 2014 IIRC. Uber will do 2bn gross this year and 5-6bn gross next year. Their financials are pretty strong.

<comment><USER29> When Uber publishes audited GAAP numbers, we'll know. Non-GAAP numbers are total junk.[1] Uber's latest "leaked" numbers still show losses.[2]

[1] [http://www.zerohedge.com/news/2015-01-08/wsj-looks-non- gaap-...](http://www.zerohedge.com/news/2015-01-08/wsj-looks-non-gaap- earnings-horrified-what-it-finds) [2] [http://gawker.com/here-are-the- internal-documents-that-prove...](http://gawker.com/here-are-the-internal- documents-that-prove-uber-is-a-mo-1704234157)

<comment><USER30> Of course they're going to be spending/losing. Why else raise 8bn? To grow.

</comment></comment></comment></comment><comment><USER31> Hopefully the recent focus on liquidation prefs is a sign they're on the way out. Definitely a holdover from the "screw the entrepreneur" era of VC.

</comment><comment><USER32> One notable exception is Snapchat which recently raised ~$500M selling _common_ shares instead of standard _preferred_ shares.

[http://nypost.com/2015/05/29/snapchat-has-sold-537m-in- commo...](http://nypost.com/2015/05/29/snapchat-has-sold-537m-in-common-stock- to-investors/)

</comment><comment><USER33> I thought that was an excellent overview of the challenges of taking too much money. (and unicorpses was a new word, I suppose once dead (or undead) they are no longer Unicorns) I think there is also an interesting retention effect on founders who have stock that is worth millions on paper if they make it work, and worthless if they don't.

</comment><comment><USER34> So does this mean that although $Bb valuations sound like we're in a bull market, it really means we're in a bear market where investors prefer downside protection over a larger share in the upside?

</comment><comment><USER35> Since very few of the unicorns are going to liquidate, I wonder how much this preference actually skews valuations?

</comment><comment><USER36> Money quote = "unicorpses"</comment>


It's Dangerous To Call Your Company The Google Of ____  - <AUTHOR> http://www.markpeterdavis.com/getventure/2010/07/its-dangerous-to-call-your-company-the-google-of-____.html

<comment><USER2> Here's the counter from Venture Hacks, using the company I founded as an example:

<http://venture-hacks.com/articles/pinch-media>

I found the 'X of Y' formulation pretty useful for getting our first round done. Maybe our experience wasn't typical.</comment>


Show HN: My boot-strapped robotics side project, HoverBot.io - <AUTHOR> https://hoverbot.io/ <comment><USER2> More offerings in the small brushless class, I like it :)

I kind of miss a video. I assume it behaves similar to other offerings in the same size, but video (outdoors and indoors at that size) would help. As would some text comparing it with alternatives and why I should buy yours and not e.g. a FlexRC MiniOwl (I'd guess yours is lighter but easier to break, but that is a guess)

Also, shipping costs? Shipping to non-US locations? (maybe I missed a page about that)

<comment><AUTHOR> The video is at the top of the page but it's a slideshow and not super clear. I'll have to make it a bit more obvious.

[https://www.youtube.com/watch?v=5xoSHdMIMYU](https://www.youtube.com/watch?v=5xoSHdMIMYU)

Good point on the comparison - I'll have to add that.

Shipping is $10 flat rate for US, and we ask non-US customers to contact us and pay the exact postage - will streamline later.

</comment></comment><comment><USER3> how do you make carbo fiber frame yourself?

<comment><AUTHOR> We have a Taiwanese ex-pat CNC the carbon fiber parts for us.</comment></comment>


How Union Pool Became the Horny Utopia of 2000s Williamsburg - <AUTHOR> https://www.thecut.com/2018/01/union-pool-the-brooklyn-bar-thats-perfect-for-hookups.html <comment><USER2> Pretty well written glimpse into someone's world.</comment>


Why we ditched PayPal for Stripe - <AUTHOR> http://gc-taylor.com/blog/2011/12/8/why-we-ditched-paypal-stripe/ <comment><USER4> The post is spot on.

My initial attraction to Stripe was because of a reason mentioned in the post: not wanting to redirect or otherwise interrupt the normal order process of my site with another company's (branded) checkout form just to handle credit card payments. The other reason for initial attraction was of course their elegant API, which was very refreshing to see after having dealt with Intuit's QBMS API ( _shudder_ ) in the past.

Stripe really sealed the deal though when I tweeted them to ask my first question about signup and one of the co-founders reached out to me. Since then, I've been in contact to share my feedback or ask other questions, and the quality and timing of their responses is one of the best I've ever seen.

When a customer of ours had an issue placing his order, I wrote Stripe to see if they could offer any insight as to what errors they might be seeing on their end. While the error was unrelated to Stripe itself, they were so awesome that they actually took the initiative to browse through our checkout page and point out the spot that they thought to be the issue.

A company that stands beside you when debugging your checkout page, maintaining swift response times on an issue that isn't even theirs? _That's_ customer support.

I probably sound like I'm gushing right now, but I just have mad respect for this company. The product isn't the only thing that's top notch, the people behind it rock too.

<comment><USER5> You almost always get amazing customer support from early stage companies. I'm certain people got amazing customer support from people high up at PayPal when it was just starting. You cannot judge a company on whether a co-founder responds to you on Twitter in a short period of time, and if you did, you should probably judge it negatively: I would wonder what was wrong with PayPal if someone that high up had enough time to be sitting around checking Twitter.

(edit: I typed this over too long a period of time, and some of this post appeared after I had already submitted a draft with the above paragraph that received some upvotes, so I've now edited again to add this edit paragraph to explain that everything after this point was added after I received said upvotes. ;P)

Also, I'm very curious about their API... I didn't see much information on chargebacks. Processors like Litle & Co make it very easy to fully automate the chargeback representment flow. PayPal, incidentally, does /not/ provide this either, but they do have APIs that let you (with only some hoops to get through bugs that I've filed with them, and we may see fixed fairly soon) correlate and track all of the chargebacks and how they relate to your transactions.

Yet, when Stripe first started appearing on Hacker News, their website seemed to have almost no information on chargebacks. I asked after this, and the page "appeared" with an apology that it was supposedly there but not linked, but it then had very little information on it. I still (checking again now) see no information on how I'd determine /which/ transactions had chargebacks automatically: they seem to seriously rely on sending an e-mail? Why does their API page never once mention the word "chargeback"?

<comment><USER4> That's somewhat a fair point, but I'll disagree.

In that instance, the co-founder replied, but I've heard from a number of Stripe's other employees since then, and in every case the customer support has been wonderful. Perhaps that's solely because they are still a startup, but given what I know now about the people themselves, I don't believe that to be the case.

I don't mean my original comment to suggest that the co-founder will always be the one to respond to a tweet as Stripe grows, but I do suspect that their standards for customer service will remain high, and _someone_ in the company will give a quick and quality response. That said, with Stripe, I believe that–even if they aren't the ones responding to every tweet, which is admittedly much to ask–the co-founders will continue to have an eye on what people are saying about them and interact appropriately, not wall themselves off.

 _Edit to reflect your edit_ :

I remember that HN thread where you brought up chargebacks. For anyone interested, they discuss how they handle chargebacks here: <https://stripe.com/help/chargebacks>

I can't attest as to why they manage chargebacks that way, and will not speculate beyond the note that they are still new and seem to be developing their service in response to customer feedback and perceived needs.

For you, or anyone else who might be interested in requesting features regarding chargebacks or any other aspect of their service, I highly recommend writing in: firstname.lastname@example.com or <https://stripe.com/help/contact>. As I mentioned, they're very responsive, and seem to love the feedback.

<comment><USER5> I am curious if you've ever actually called PayPal. I have received nothing but high quality support from them. You can call them throughout most of the working day (until 8pm PST, I believe), and they seem to have somewhat knowledgable engineers available at that tech tier. They also have a merchant technical support site that seemingly no one knows about where you can often get answers in the middle of the night (I often get responses back at 12:30). If you are even reasonably sized you can also ask for a dedicated account manager: I have the cell phone number of someone at PayPal whose job it is to find me answers to problems I have.

Though, I cannot say PayPal is perfect. I have run into a bunch of annoying issues correlating settlements (bugs filed recently, will be curious to see if they get fixed), and their pricing is not the best that is out there (although is still better than Stripe). I am curious if you've looked into any alternatives. I've spent the last few days talking to Litle & Co, and I must say that the people there /love/ talking to you about payments... their booth at ad:tech was the most enjoyable conversation I've had about payments in a while, and I got to spend another half hour on the phone with them yesterday learning more about how bank ACH settlement works.

 _Edit to reflect your edit ;P_

That is the page I just had gone and reviewed now. It still seems incredibly manual. I would not feel comfortable running a site at scale where I'm dealing with receiving e-mails in an undocumented (probably designed-for-humans) format as my only source of notifications for chargebacks. :(

It is often these "at scale" issues that are seemingly not handled by them; example: per their API page, Stripe does not resend webhooks if there is an error in the response... doesn't this make them useless to rely on? Am I required to sit around and poll my transactions to feel 100% certain that I didn't miss something because my load balancer accidentally gave them a 503 during some traffic spike? :(

<comment><USER4> I have called PayPal once before. The experience wasn't horrible, but it didn't leave me enthusiastic like Stripe's does. I'm not holding that against them though: it's only one mediocre experience, and I have not used them much because of the whole payment redirection thing (I did not know about their _Pro_ account then).

To be clear: I'm not actually saying that PayPal is bad. I don't have enough experience with them to weigh in one way or the other. I am merely saying that I _do_ like Stripe.

I'm not sure of Stripe's reasoning behind not resending webhooks, but I don't know that I care for them not resending them either. Perhaps this is something they'll be addressing in the future or otherwise have a legitimate reason.

<comment><USER6> _I have called PayPal once before. The experience wasn't horrible, but it didn't leave me enthusiastic like Stripe's does._

Well, talking of facts small companies with a small customer base will always deliver better customer service than the larger ones. True test of these companies will come when their subscriber and customers run into millions(In paypal's case hundreds of millions).

Imagine a situation where where 283 million registered customers and probably more unregistered buyers. Ensuring operations related to that magnitude of people work fine for 99.99% of the people, 99.99% of the times. And then ensuring the remaining get appropriate customer support is not just difficult but requires a lot of work to maintain and run.

At that scale the founders will have a lot more different work to do. And addressing one user out of those hundreds of millions by communicating them on twitter might not scale properly. And the customer support employees are working in call center shifts. They are not going to be any more enthusiastic any more than other general call center employees.

Coming to arcane policies, Now for all those millions of users. There are definitely going to some x% of crooks out there gaming the system. Frankly speaking if you don't have such policies you may actually end up putting a lot of your other buyers and other customers in trouble and expose them to fraud. The problem is in programmatically handling hundreds of millions of users and their problems is not easy. You can build a system to do payments et al, but that's only beginning. So any good payment gateway etc will ultimately end up looking like PayPal.

PayPal works at a scale, Whether a new competitor will work at scale is question of time.

But don't write PayPal off, It actually works well for those hundreds of millions of registered and more unregistered users.

</comment></comment></comment></comment></comment></comment><comment><USER7> The better question would be "why _wouldn't_ you ditch paypal for stripe?"

Stripe is much easier to integrate than the x.com/paypal.com family of conflicting api's, all of which lack easy to read documentation.

[https://cms.paypal.com/us/cgi-bin/?cmd=_render- content&c...](https://cms.paypal.com/us/cgi-bin/?cmd=_render- content&content_ID=developer/howto_api_reference)

Compared to

<https://stripe.com/docs>

Stripe doesn't have a history of randomly locking accounts, and even if they do (if you process payments, I can understand the legal need to now and then) their customer support is so responsive and helpful I wouldn't really mind.

Stripe is easy to use. The web UI is fast, the api makes sense, I get joy out of it.

Stripe sent me a real, physical letter, to thank _me_. I was one of the early users of the beta, and we all got real letters, on thick cardstock, I wish I had taken a picture of it. That may be a virtue of being a small userbase startup, but if you start with that mentality, it means a lot.

Paypal does have slightly lower fees, but Stripe is worth it.

Paypal also makes it easy to add a paypal pay button to sites, but those a fraught with stories of accounts shut down, and are ugly.

<comment><USER8> I can only see two reasons why someone might need PayPal rather than Stripe: if the business resides outside the US, or if they need to take methods of payment other than credit cards. Other than that, Stripe seems like a no- brainer.

<comment><USER9> Josh, you are failing to recognize other reasons why a business might still consider using Paypal as their merchant account provider. Here are ours:

1) Costs. We pay 2.2% + $0.30 USD per transaction vs. Stripes' 2.9% + $0.30 USD per transaction. At our transaction rate, that makes a difference in received revenue.

2) Moving. Refactoring a well established business to interface with a new payment provider can be a costly and expensive process. Think of switching personal banks.

3) Fraud. Paypal probably has the most advanced fraud protection in the online business today. If you deal in any decent amount of online payments you will find this to be a huge issue.

Additionally, we have our own dedicated Paypal account manager that actively reaches out to us and keeps in contact, and we can instantly call a _direct line_ to this person if we need assistance with an issue.

With that said, our team is actively looking at Stripe because we like the ease of use when it comes to reoccurring payments, which we don't do at this time but plan to implement in the coming year. From what we see, reoccurring payments are a messy with Paypal and I'm not satisfied with Paypal's solution compared to their competitors like Recurly, Chargify, and, well, Stripe. But I am impressed with what Stripe has to offer on all fronts. Especially their API which appears to be very easy to use. ...And, they have a nice looking reoccurring payments process which fits our vision nicely.

Anyway, disclaimer: we run between 50K and 100K a month through Paypal, so that is probably why we get fantastic support from them and better pricing.

</comment></comment></comment><comment><USER10> I'm the lead API engineer at WePay, so I'm definitely biased toward the WePay API, but I do think Stripe is a great service.

The WePay API does allow you to embed the entire checkout experience on your own site with our iframe checkout. The iframe contents are customizable (header color, button color, etc), but as Greg mentions in the comments, it's not quite as customizable as Stripe or another merchant account based system.

Unfortunately, even with Stripe, you are still liable for _most_ of the PCI spec (our iframe checkout gets around this). We made a bet that there are a lot of developers out there that who are willing to give up a little on the customization side to not have to deal with the headache of PCI compliance (we've gone through that process ourselves and it is complicated and expensive).

<comment><USER11> Out of curiosity, how does an embedded iframe let you avoid PCI completely and an external javascript lib not?

<comment><USER10> The external javascript library is still being loaded on a page served from your domain, so it's totally possible for you to grab the credit card data and ajax it to your server (or for an XSS vulnerability to allow a 3rd party to send it somewhere). Since the CC info is accessible to both the client and Stripe, both are liable for PCI compliance. [edit: just to be clear, with stripe, you aren't liable for _all_ of the PCI spec (just part), which is one of the awesome things about the service]

With the iframe, the checkout form is served from WePay's domain, so javascript on your page can't directly access elements on the checkout form. There are still potential vulnerabilities such as clickjacking (we do some things to protect against this), but since the CC form is served from our domain, only we are liable for PCI compliance.

<comment><USER12> We at Stripe (and more importantly, our PCI auditors) don't agree with this assessment of how the chain of responsibility works.

When you use Stripe.js, you need only serve your page over SSL and verify that you aren't collecting credit cards through other means to be PCI compliant.

<comment><USER13> We don't do PCI assessments (I have a generally low opinion of the process), but we do the "real" appsec work for lots of companies that do, and the impression I have is that --- counter to what you'd expect --- 'boucher is right, and you can self-assess using their interface, despite the fact that anyone doing so is in fact an XSS flaw away from giving up cards.

In particular, while I have no idea whether Stripe's implementation is letter- of-the-law PCI compliant, I do know that 'LeBlanc's reasoning is not PCI reasoning (particularly: you can't draw a line from architectural susceptibility to "liable to audit") --- even though it's the reasoning I myself would use.

<comment><USER14> Interestingly, PayPal actually offers (or offered?) an iFrame checkout for some customers and it was confirmed to be PCI-compliant. But again, another PCI auditor might have another opinion on it :)

<comment><USER15> Paypal actually offer a Embedded payment experience which in no sense gives the feeling of embedded payments on the website. [https://cms.paypal.com/us/cgi-bin/?cmd=_render- content&c...](https://cms.paypal.com/us/cgi-bin/?cmd=_render- content&content_ID=developer/e_howto_api_APIntro)

On this link you can find the experience of Embedded payments, i implemented it on our site but the docs on the api are not complete on paypal, rather complete they are not present at one place.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> I don't really consider Stripe a replacement for PayPal. You don't accept PayPal because it can process credit cards, you accept PayPal because millions of people want to pay with it. Don't get me wrong, I hate PayPal just as much as the next guy, but unfortunately it isn't a viable option to stop using it in favor of simply accepting credit cards right now (though Stripe is an awesome product!).

<comment><USER17> Very true. Here's another example:

My wife sells knitting related things (patterns, books, yarn) on ravelry.com. They collect the payment for her and transfer the money to her paypal account. I suspect it will be a while before stripe can do such a thing.

<comment><USER18> If ravelry.com used WePay, each time someone bought one of her amazing works of art, the money would be deposited directly into a FDIC insured account that your wife controls.

From there, your wife could transfer the money directly into her own regular bank account.

If ravelry.com goes out of business before they transfer the money to her paypal account, there is no chance that they can take any of her money with them. (While highly illegal, I've seen this happen elsewhere with a similar setup.)

<comment><USER19> *ravelry, not raverly

<comment><USER18> Fixed. Thanks. Must be my old school raver roots. Heh.

<comment><USER20> raver you say? Do you know of any good bay area raves?

</comment></comment></comment></comment></comment></comment><comment><USER21> From what I understand, one of the differences between WePay and Stripe is that WePay allows marketplace transactions where the app creator can take a cut of the transaction (similar to Paypal's adaptive payments API). I don't believe that Stripe allows marketplace transactions. WePay doesn't currently handle the dunning process for recurring payments but they plan to do so at the beginning of the year. Stripe currently handles the dunning process. At Bellstrike, we use WePay's API and have had nothing but good things to say about them. Their customer service is outstanding and we always have access to their developers, usually within minutes. We're getting ready to implement their iFrame solution as well. I've talked to some others that are using Stripe and they are pleased - particularly with the fact that Stripe only requires the credit card number and expiration date for a transaction - <USER2> other info. I guess it just depends on what you're looking for but I'd recommend WePay from my experience. We had a terrible time with PayPal.

<comment><AUTHOR> I too heard lots of great things about WePay. They seem like a great shop.

As you've noted, there are some differences in feature sets on both sides. However, perhaps there will be some convergence in the future. Both services are very young, and improving very rapidly.

</comment></comment><comment><USER22> Both WePay and Stripe are US only.

[https://www.wepay.com/Does-WePay-allow-international-non- US-...](https://www.wepay.com/Does-WePay-allow-international-non-US-payments) <https://stripe.com/help/faq>

So for now, I am stuck with Paypal.

<comment><USER23> I'm starting to think though, that it's a good opportunity for others in other countries. Stripe, Twilio, Google Voice, probably a bunch of others.

</comment></comment><comment><USER24> I would love to be able to use stripe instead of PayPal, can't wait until it's available in the UK.

Unfortunately they don't even have a timeline for availability outside of the US yet - <http://twitter.com/#!/stripe/status/144951134795218945>

</comment><comment><USER18> WePay doesn't require you to redirect them to their site.

<https://www.wepay.com/developer/tutorial/iframe>

<comment><AUTHOR> Perhaps "redirect" wasn't the best word to use. WePay does interrupt the flow of your site with their own system, however:

"The iframe checkout lets you embed an iframe on your own site that will contain the WePay checkout system."

With Stripe, we have 100% control over presentational stuff during checkout.

<comment><USER18> Sure, if you want that level of control. In my case, I was happy to not have to implement that part of things. It isn't a trivial amount of work to deal with the credit card / address forms and get everything correct. I made the iframe look like a part of my site well enough that people can trust it and it saves me a ton of development time.

Your app appears to be in private beta, so I can't test that form to see if you missed anything and post about it here. ;-)

<comment><USER25> hey guys - bill from wepay here.

we contemplated building a JS solution as well, but using JS can place your site within the scope of PCI compliance. (this is somewhat up for debate) the reason we went with an iframe implementation is because it is firmly outside the scope of PCI, and we are working on making it even more customizable.

either way, you are in good hands with stripe or wepay. (at wepay we are big stripe fans - they rule!) to me, the big difference is whether or not you want the money to settle to someone's bank account directly (stripe), or whether you want it aggregated and stored in an online account first (wepay).

</comment></comment></comment></comment><comment><USER26> I feel like I am becoming a ridiculous Samurai supporter in a world of Stripe supporters on HN (odd because we know they have many large customers), but my large (seasonal business, 8-figures a month for 5 months a year) contract employer chose Samurai last month and we've been very pleased. We still are splitting our transactions between them and another provider but we've been very satisfied w/ Samurai thus far and will probably migrate all of our transactions to them over the next couple of months. They have an amazing API - can do the stuff referenced in the above article... See: <https://samurai.feefighters.com/developers/samurai-js> and were fantastic to work with. They also have a campfire room that is usually staffed and helpful

I ended up choosing them for my non-day-job gig as well (saas business) and am very happy. Happy that both of these services exist, really.

</comment><comment><USER27> We switched to Stripe from Paypal and Google Checkout a month ago and so far I've been very, very pleased. I plan to do a writeup of why we switched soon - wanted a bit more results first. FYI, Stripe launched a new web interface 2 days ago.

The net bottom line was this: 1\. our customers (business people who are not super tech savvy) just don't understand that you can pay with a credit card on paypal and google checkout requires a google account 2\. the "go off and pay" somewhere else and come back to the main site is messy

I have no real complaints with paypal over the years we used them so I can't bash them but I found that over time, we lost sales because people were confused. Now there is no more confusion - fill in a few fields and instantly you are done.

We also considered Braintree which I was also impressed with but decided on Stripe because of the non-need for a merchant account.

I am happy to answer any questions here or privately if needed.

<comment><USER28> Stripe does provide you with a merchant account (<https://stripe.com/terms>). They just make it a simple process by asking for as little info up front as possible. There's advantages to this such as a quicker sign up process. But the disadvantages are that you may have issues if your company grows too fast, if you get too large of a transaction size or a host of other risk issues. Your best protection against these is giving the bank the option to perform a thorough underwriting. Disclosure: I work at Braintree.

<comment><USER29> I work at Stripe. This is pure FUD. If fast-growing companies really did encounter problems with Stripe, don't you think at least one would have talked about it?

</comment></comment></comment><comment><USER30> "We investigated some traditional payment processors like Braintree and Authorize.net ... A lot of traditional gateways have long, complicated setup processes, often involving sales calls and working with banks. ... They also typically require you to send credit card data through your servers, which means obtaining a level of PCI Compliance (not that we aren't already security-conscious)."

I've used both of these. Braintree may not have been the right choice in their situation, but grouping them with Authorize.net for these reasons isn't really fair. Braintree's bundled merchant account and gateway services are much easier to set up, and their transparent redirect eliminates the need to handle card data on your own servers.

And in my experience, their "We (heart) developers" motto is, well, true. They have really great, friendly support. Braintree and Authorize.net are miles apart. At least as far apart as Stripe and PayPal.

</comment><comment><USER31> The usual gripe - my company is based in New Zealand, and it's well nigh impossible to open a US bank account so we can't use Stripe or Wepay. I'd love to know how many of PayPal's merchants are non-resident, it's the only reason we use them.

In fact, if it wasn't for PayPal non-US websites selling to the US would be almost impossible. The US has a massive advantage in that the rest of the world is happy to pay in US dollars, but US citizens won't pay in other currencies.

So here's a very lucrative challenge, Stripe and Wepay: the one that figures out how to allow non-residents to set up an account first simply has to post the news to HN and will be flooded with new accounts. I'd switch within 24 hours if there was a viable alternative to PayPal.

<comment><USER32> In tepid defense of US customers - even US banks can't really figure out foreign currency. We went to the bank in Bloomington, Indiana to exchange some Euros we had laying around and they literally had no way to handle them. The best they could offer was to _mail_ them to American Express. Or drive to the airport in Indianapolis. And this wasn't a local bank, it was Chase Manhattan's branch in Bloomington.

We ended up driving to the airport in Indy. No way am I just going to put a few hundred Euros in cash into the mail.

</comment></comment><comment><USER33> More positive news about Stripe since the last time they were posted on HN. <http://news.ycombinator.com/item?id=3053883>. I will give them a try on the next e-commerce project I work on.

</comment><comment><USER34> I hear you. However I would like to point out that the two PayPal services I designed 10 years ago, Web Accept and IPN, continue to work in the same way they did a decade ago. I was fanatical about not breaking and not needing to version.

</comment><comment><USER35> Can anyone recommend something similar to Stripe or WePay for Canadians.

</comment><comment><USER36> Please come to Australia; I'd love to use Stripe for new projects.

</comment><comment><USER37> I'm eager to try stripe myself but it wasn't right for our business due to the transaction costs. We do anywhere from a quarter to half million per month in transaction fees and it's amazing how those fractions of a percent and one penny turn into thousands of dollars! We looked at losing about $20k per month so it didn't make sense.

But I have a generic payment processor API that I wrote and I plan to add support for stripe into that for personal projects.

</comment><comment><USER38> Redirects are a _good_ idea. Redirects mean that you don't have to juggle legally sensitive credit card data yourself, and your customers see a browser indication that they are talking to the genuine Paypal (or whomever).

Paypal sucks, blocks your account and keeps your money on the least excuse, and is a bureaucratic hell, those are good reasons to not use them. Redirects aren't, IMO.

<comment><AUTHOR> You don't need to choose between safety and no redirects. One of the major points of the article is that you can not touch the credit card data yourself, AND still get a 100% uninterrupted payment experience for the user.

Again, it's still early, but we are seeing better conversion rates so far. The PayPal redirect gave some of our less technical users fits.

</comment></comment><comment><USER39> So how exactly do you replace Adaptive Payments with Stripe?

I'm probably missing out on something here.. I know that flaming PayPal is popular nowadays but I can't find an alternative with both Authentication and Adaptive Payments (which our app is completely based on)

</comment><comment><USER40> Can someone explain why Stripe doe not allow marketplace transactions but WePay does? Is this primarily due to issues of fraud? If so, how does WePay get around it?

</comment><comment><USER41> Sounds like one of the main advantages of stripe is the API.

I wonder if anyone is working on making payments platform-independent so it's easy to switch between payment providers.

<comment><AUTHOR> Most of the gateway-style services operate very similarly. We wrote some abstractions to allow us to eventually add Braintree or Authorize.net, since the payment cycles are much alike (from the API perspective). It only gets difficult when you try to mix-and-match something that uses redirects/iframes with services that deal directly with credit cards from your server to theirs.

We just don't want to get into PCI audits and scans just yet, but once we do, we'll probably use Stripe's direct server->server APIs like Braintree/Authorize.net do instead of stripe.js.

</comment></comment><comment><USER42> Why on earth Europe doesn't have something like Stripe or WePay ?? This is such an amazing opportunity, and I can see lots of people who would invest in it.

<comment><AUTHOR> Dealing with all of the banks, currency, and laws sounds like an absolute mess. Each country does business differently.

</comment></comment><comment><USER43> US only. The only reason I hate living in Australia.

<comment><USER44> Or the UK. Bane of my existence.

<comment><USER45> We should setup a payments service that works everywhere, except the US. Revenge ... kidding. Although given how dodgy the PayPal APIs are and that future economic growth is likely to be based outside the US, it might be a very viable business.

</comment></comment></comment><comment><USER46> Sigh. another great looking payments service thats only available in the US. doesn't anyone want my ruples?

</comment><comment><USER47> I'm not enough of a developer to integrate completely with stripe, but we've been making the change to Dwolla.

Anything is better than PayPal. I appreciate their contributions to epayment, but their time has passed.

Other great options out there include Square, MoneyBookers, and Dwolla (if anyone is looking to leave PayPal after this article and the recent Regretsy one).

</comment><comment><USER48> I was absolutely enthralled with the support I received in their Campfire chat.

</comment><comment><USER49> You may want to also consider SaaSy.com: \- All-inclusive – hardly any development work needed - More functionality - GUI-based for the most part - Global tax/VAT management - Works with vendors in most any country - <USER3> currencies - 20 languages - Best customer service experience of your life

<comment><AUTHOR> To be perfectly honest, this is pretty far from the discussion. SaaSy looks expensive, and their website isn't even clear enough to see if they offer the redirect-less single payment checkout.

I'm assuming this is just a shameless plug? Nothing wrong with that, but it looks like you don't even have the feature set the original article is discussing.

Edit: Oh, I see what's going on: <http://news.ycombinator.com/threads?id=fastspring>

</comment></comment><comment><USER50> I cannot recommend Stripe enough. We will be posting a blog post about our (seamless, instant) transition very soon. Kudos!

EDIT: By seamless, I mean "Sign up and get an API key", and by instant, I mean "Read this article, sign up, instant activation, plug in API keys, start charging, switch complete!"

</comment><comment><USER51> Why you'll be losing a lot of business

</comment><comment><USER52> <https://twitter.com/#!/hm2k/statuses/119216249774411777>

<https://twitter.com/#!/stripe/status/119221741259206656></comment>


Break Apart Your Backbone.js Render Methods - <AUTHOR> http://ianstormtaylor.com/break-apart-your-backbonejs-render-methods/

<comment><USER2> Another great article, Ian. As a newbie to Backbone, I find myself refactoring and going over best practices frequently. One of the first things I found myself trying to wrap my head around is different ways to render my templates properly. This seems like a good approach when you have pretty distinct modular chunks that are reusable.

Rivets does look promising in that there are some parts of my code in templates that are just a single number (say # of notifications). That's a pain to have to separate out into a separate view or render function for something so small.

<comment><USER3> > I find myself refactoring and going over best practices frequently.

I'm curious, what kind of changes have you adopted to as a result?

</comment></comment><comment><USER4> This is not a problem specific to backbone rendering. This is a common issue in jQuery plugins, and vanilla javascript in general. Its a best practice overall to keep your functions small.

Have them do one thing and do it well, keep them unix like, small sharp tools. You can always copy paste a large conditional from one function into its own named function. This significantly improves readability and divides the code in to smaller units which makes testing more graceful.

</comment><comment><USER5> What made you choose this setup over subviews (with one render per subview)?

<comment><AUTHOR> It's just a question of how many subviews you want to make. In this case, I don't really think the label itself needs to be a subview since its such a simple component. The only action I associate with labels is for clicking them to focus their associated input. Which wouldn't even be pulled into a LabelView, so there's really nothing to it, so I don't gain much from separating it into its own view.

You can probably argue both ways though, I used to have labels be their own view actually. It just got a bit more uselessly complicated for so little benefit.

If the view you're dealing with is an end node in the view hierarchy (and it's pieces are relatively simple) then I prefer not to split them up because there are costs there as well.

<comment><USER6> This is the problem I run into every app I make...when I try subviews I usually end up giving up out of annoyance at the complexity

<comment><AUTHOR> Dunno if it will help, but I wrote earlier about how I handle rendering subviews: [http://ianstormtaylor.com/rendering-views-in-backbonejs- isnt...](http://ianstormtaylor.com/rendering-views-in-backbonejs-isnt-always- simple/)

</comment></comment></comment></comment><comment><USER7> the problem the author is solving is clear; _"Instead of writing gigantic render functions that do everything under the sun (and then more, admit it!) you should break your render methods into small chunks. That way you only ever re-render what you need."_

but breaking apart your render method is only one way to achieve this. using a sane layout manager with subviews is my preferred approach (though i suppose you could argue this is just breaking up the render method across several views). this technique is also admittedly a pain at small scales.

the beauty of this technique, though, is that every view is responsible for it's own rendering. that is, parent views don't need to be aware of the re- rendering process of their subviews (how or _when_ ). another great benefit is you will find yourself referencing items by selector less often, and instead through the subview's element.

<comment><USER8> I do structure my code in a similar way. All the elements in a view, that have to deal with data, are treated as a separate view module. Each module will have it's own view, template, model and style.

The template for the main view, or the subview that can hold modules,is structured in such a way to have a .container to append my modules into.

The main view is usually rendered only once and behave as a proxy for the various modules relying to the events.

The great benefit form this approach is that it's quite easy to maintain/replace a single module as long as the events api don't change.

<comment><USER7> awesome, yep. sounds nearly identical to my tactic; with 2 minor exceptions. first being i don't necessarily have a unique model for each view- lots of times my subviews use the same model as the parent or sibling views.

second is i actually define the sub views element from the parent view on instantiation, and operate under the assumption that all subviews will render by emptying their element and replacing it's contents. the primary reason is so the root subview element never changes (which can lead to complexity).

<comment><USER8> Same here for subview rendering.

About the models I prefer to use an unique one for maintenance and team development cause it's harder to accidentally break things.

</comment></comment></comment></comment><comment><USER9> Doesn't this necessitate lots of individual templates? (in this example: inputTemplate, labelTemplate...)

Is there an easy way to manage this? From what I've seen it's typical to have one template per view (and possibly sub-views with sub-templates).

<comment><AUTHOR> Dunno about easy, but we use Require.js with either the text! plugin or a custom plugin for jade templates, so they're in their own files.

</comment></comment><comment><USER10> <https://github.com/theironcook/Backbone.ModelBinder> really helps with this problem.

</comment><comment><USER11> May I suggest more line breaks, and fewer inline if statements. The two would make your code more readable.

<comment><AUTHOR> Maybe. I've actually adopted the style from Backbone itself. [https://github.com/documentcloud/backbone/blob/master/backbo...](https://github.com/documentcloud/backbone/blob/master/backbone.js) I've found that while it make individual methods harder to read, maybe, it helps with readability of the file in general. If your methods stay small and are well named, you don't need to read their internals as often, but scanning the file quickly, it's much easier to get a big picture.

I used to be very liberal with line breaks, but then seeing methods as their own blocks gets harder. It's just a trade-off. Those example methods could probably use a single line break each, I'll give ya that :p</comment></comment>


Elon Musk's big battery brings reality crashing into a post-truth world - <AUTHOR> https://www.theguardian.com/commentisfree/2017/jul/07/elon-musks-big-battery-brings-reality-crashing-into-a-post-truth-world?CMP=fb_gu <comment><USER2> Previous discussion on this topic: [https://news.ycombinator.com/item?id=14723853](https://news.ycombinator.com/item?id=14723853)

</comment><comment><USER3> I'm sure that was posted earlier today.

<comment><USER4> you can breath some value into your comment by adding a link to the previous discussion. else just flag.

<comment><USER3> Sorry I was on mobile so not easy. Point taken.</comment></comment></comment>


Rackspace:"We Have Work To Do" - <AUTHOR> http://www.datacenterknowledge.com/archives/2009/11/04/rackspace-we-have-work-to-do/

<comment><USER2> My understanding is this was not a RackSpace problem, but an employee error shorting out a high voltage circuit that took down a large section of their electrical distribution. Human error. Lucky the Engineer performing the upgrade was not electrocuted.

As far as the recovery time goes, server farms do not always reboot and come online like XP Pro on a laptop in Starbucks. Their people seem to have worked diligently to bring their infrastructure back up as fast as it humanly could be done. So personally, I think we should view Rackspace's handling of this crisis as a homerun.</comment>


More than 35,000 mail-in ballots were rejected in Florida primary - <AUTHOR> https://www.politico.com/states/florida/story/2020/09/17/more-than-35-000-mail-in-ballots-were-rejected-in-florida-primary-1317327 <comment><USER2> A couple questions/comments.

1) Why should an unsigned ballot be considered a vote? Why is it being reported as though its conspiracy?

2) In a swing state, a random batch of ballots will likely be very tight, like 48/52 for either candidate, so 1.5% of the mail in ballots going uncounted should be something like 1.5% times 4% of 2.5mm anticipated mail in ballots means 1,500 critical swing votes in a state with nearly 10,000,000 voters.. well that seems like pretty strong results.

3) I always think, if that's the best the chaos monkeys can do, then I think I feel pretty good about the process?

4) Is following the stated and simple rules that 98.5% of the other voters managed to comply with, for the special dispensation of getting to vote remotely really all that burdensome?

<comment><AUTHOR> > 1) Why should an unsigned ballot be considered a vote? Why is it being > reported as though its conspiracy?

It shouldn't be counted. But it does show that there is some "unreliability" in mail-in votes, in that people can't follow the instructions and forget to sign it.

> as though its conspiracy?

Well, it is Politico

</comment></comment><comment><USER3> The US has a problem because it let's States decide their own elections. But then because of the electoral system, a few states decide the whole thing. Its an invitation for small problems (or local corruption) to become an (inter)national issue.</comment>


Google wave invites going for ~$100 on ebay - <AUTHOR> http://cgi.ebay.com/Google-Wave-Advance-Access-Invitation_W0QQitemZ190338773533QQcmdZViewItemQQptZLH_DefaultDomain_2?hash=item2c5113321d&_trksid=p3286.c0.m14#ht_500wt_1182

<comment><USER2> 12 bids, $100: [http://cgi.ebay.com/Google-Wave- Invite_W0QQitemZ320430457658...](http://cgi.ebay.com/Google-Wave- Invite_W0QQitemZ320430457658QQcmdZViewItemQQptZUS_Software?hash=item4a9b24c33a&_trksid=p3286.c0.m14)

9 bids, $102,50: [http://cgi.ebay.com/Google-Wave- Invite_W0QQitemZ280403832589...](http://cgi.ebay.com/Google-Wave- Invite_W0QQitemZ280403832589QQcmdZViewItemQQptZUS_Software?hash=item41495eef0d&_trksid=p3286.c0.m14)

Also, this:

        Startup idea: an eBay system to sell invites you get from Google Beta programs.

\- <http://twitter.com/migueldeicaza/status/4506427752>

</comment><comment><USER3> They're a waste of money at any price. I hear from a friend who activated his wave account this morning, that you can't create a wave account that has the same name as a gmail account. So it seems very likely that all gmail accounts will eventually be wave accounts someday anyway.

<comment><USER4> When I got access to Wave a few months ago, it was not possible to associate Gmail accounts with Wave at the time.

I am guessing that with the new rollout, they have made it possible.

<comment><USER5> My Wave username is the same as my Gmail one.

</comment></comment></comment><comment><USER6> I'm stupid, I had 8 this morning! Now I only have 8 happy friends ... ;)

<comment><USER7> Did your friends actually get into Wave or are they just on the (very very long) list? There's a huge amount of invite begging going on but it's not clear that these "invites" are worth anything.

<comment><USER8> As far as I know, all are on the long list.

</comment></comment></comment><comment><USER9> People were bidding crazy money for gmail invites a while back, too.

</comment><comment><USER10> Human herd behaviour at it's best.

<comment><USER11> I can moo better than anyone, just try me!

</comment></comment><comment><USER12> These are Sandbox invites. In all likelihood your gmail account will become your wave account and the sandbox accounts may or may not stay alive as developer accounts. Spending money on invites is pointless.

<comment><USER13> so these are for the wavesandbox.com dev server? i got in on the first (uh..) wave of invites ages ago, but haven't received any codes today.

<comment><USER12> Yes (as far as I know). My wife got one yesterday and it was for wavesandbox.com.

Edit: I was wrong. The new invites are for the production server.

</comment></comment></comment><comment><USER14> Hmm, I've had google wave for some months now, and I somehow don't see much a use for it at the moment.

</comment><comment><USER15> Hmm. Glad I didn't pay for mine. I'm sitting here playing with myself in a solitary Wave...

Who wants an invite to my Wave? You've got to already have an Apps account @ googlewave.com.

<comment><USER16> Sure, just send me one of your invites ;)

</comment></comment><comment><USER17> This is silly! How many degrees of separation are there from someone with wave invites...

</comment><comment><USER18> Can anyone send me an invite please? My email is peteris.krumins---gmail.com. Thanks! (replace --- with @)

Edit: I wonder why this is getting downvoted. This seems a completely ok comment to me.

Edit2: A good person just notified me that he has sent me an invite! Thanks dan!

<comment><USER19> can you get me an invite? i'd really appreciate it. drkrool--gmail--com

</comment></comment><comment><USER20> Everyone wants to be one of the first.

<comment><USER21> It's not even an immediate either. They are paying to stand in line.

<comment><USER22> Like Amazon pre-orders.

</comment></comment></comment><comment><USER23> Buy it now 75$ ! [http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=30035...](http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=300352956461&ssPageName=STRK:MESELX:IT)</comment>


Why Cloudflare Chose AMD EPYC for Gen X Servers - <AUTHOR> https://blog.cloudflare.com/technical-details-of-why-cloudflare-chose-amd-epyc-for-gen-x-servers/ <comment><USER2> I really wish AMD would focus on its tooling. The Intel VTune Amplifier is a fantastic multi-platform profiler that can help understand how effectively your software is using the hardware (Pipelining, micro-ops efficiency, cache usage, etc.).

If AMD could come up with something similar, it'd make their offering a no- brainer.

> [https://software.intel.com/en-us/vtune](https://software.intel.com/en- > us/vtune)

<comment><USER3> I doubt tooling is the problem that is slowing down AMD adoption. Compiler or special applications writers care about that. These are not the ones who pay AMD for their platform. It's the big businesses - most care about stability, predictability, reliability hence they stay with Intel. Those that are interested mostly in bang/buck, like Cloudflare, choose to go with AMD, tooling or no tooling. You don't need tooling to check that AMD is far more efficient now, you just do some basic load tests and the result is easy to understand.

<comment><USER4> If you have crappy tooling, the software other people write -- in house or commercial software-- runs crappier on your hardware.

<comment><USER5> But it's irrelevant if it works faster than intel

<comment><USER6> It's not irrelevant if Intel has tools to let you close that gap easily.

<comment><USER7> Tools can't close a gap of entire cores, much less twice or more of them.

<comment><USER8> It's a matter of principle.

Some people don't want cores that you can't gather insight into how you are spending/wasting their time.

I'm not a direct customer of Intel or AMD, but in general I would trade off clock speed/cores/cost for insight into what my software is doing.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Yes, there are lots of stories of individuals and companies choosing AMD over Intel. For me, what's more interesting would be any _contrarian_ view listing the compelling reasons to pay the higher price for Intel instead of AMD. Off the top my head, some reasons would be:

\- Intel AVX-512 instruction set

\- Intel 4 and 8 sockets

What realistic workloads have a better performance/cost advantage on Intel vs AMD EPYC?

If you're a home user (gamer, programmer), is there any reason to buy Intel today? I'm about to buy another motherboard & CPU and considering AMD for the first time. In the past, I avoided it because AMD had an incompatibility (e.g. VMware) that kept me on Intel.

(E.g. previous example of AMD showstopping bug affecting VMware: [https://communities.vmware.com/thread/456094](https://communities.vmware.com/thread/456094))

<comment><USER10> > If you're a home user (gamer, programmer), is there any reason to buy Intel > today?

If you need EEC ram?

I know technically AMD supports it for their Ryzen line, but everything I've read says it's up to the motherboard manufacturer to support it. And even if the motherboard manufacturer says you can use ECC ram, it doesn't mean it will actually "use" it correctly.

So you mainly need to rely on others doing tests on their own systems to confirm if the motherboard actually uses it.

My understanding is that you need to use the EPYC line for guaranteed ECC usage, which is really expensive.

Intel's W series Xeons start off at a reasonable price, and there are even cheaper Celerons that will use ECC ram.

<comment><USER11> > _I know technically AMD supports it for their Ryzen line, but everything > I've read says it's up to the motherboard manufacturer to support it._

AFAIK every ASRock AM4 motherboard supports ECC.

Also, most Intel processors do not support ECC at all, except the ones which are competing (in some limited sense, since they are being absolutely _crushed_ at most price points) with Threadripper, in which case, ECC is available across the board (and glorious quad-channel memory).

</comment></comment></comment><comment><USER12> At FAAG its well known that some AMD procs are faster, cheaper and cooler(well higher performance per watt). None of that is in doubt, what they are having trouble with is supply.

It appears that AMD are not able to provide either the support (microcode tweaks, firmware heads up, firmware testing and bug reporting) or the volume to be useful.

The conclusion was that AMD want to nail consumer first.

</comment><comment><USER13> SourceHut runs its performance critical infrastructure (git, builds) on AMD EPYC. These CPUs are sweeeet. The hard part is sourcing motherboards. I currently buy them from some dude in Germany on eBay because he's the only consistent source I've been able to find.

<comment><USER14> > SourceHut runs its performance critical infrastructure (git, builds) on AMD > EPYC. These CPUs are sweeeet. The hard part is sourcing motherboards. I > currently buy them from some dude in Germany on eBay because he's the only > consistent source I've been able to find.

Heh, you know that guy is with / getting a visit from the German BDN now.

<comment><USER15> *BND, from Bundesnachrichtendienst

<comment><USER16> Why, is it illegal?

</comment></comment></comment></comment><comment><USER17> Two years ago they switched to ARM [https://news.ycombinator.com/item?id=16646701](https://news.ycombinator.com/item?id=16646701)

<comment><AUTHOR> We tried to switch to ARM. We maintain our ARM port of all our code for the day there are servers we can use. However, we are in production with AMD now.

From one of the posts: "Readers of our blog might remember our excitement around ARM processors. We even ported the entirety of our software stack to run on ARM, just as it does with x86, and have been maintaining that ever since even though it calls for slightly more work for our software engineering teams. We did this leading up to the launch of Qualcomm's Centriq server CPU, which eventually got shuttered. While none of the off-the-shelf ARM CPUs available this moment are interesting to us, we remain optimistic about high core count offerings launching in 2020 and beyond, and look forward to a day when our servers are a mix of x86 (Intel and AMD) and ARM."

<comment><USER18> Do you see any ARM chips on the horizon this year or next that might change the equation? It looks like Amazon is seeing 40% better performance per watt (I think they said the power draw is comparable somewhere) with their custom design, will a commercially available chip be able to match that soon?

Side note: Thanks for making a great product and keeping it cheap/free for hobby projects! I got comfortable with the basic features on a small project and now advocate for it's use regularly.

<comment><AUTHOR> We continue to look at ARM and test things. We continue to look at Intel and test things. Right now AMD makes the most sense for the servers we are deploying today. But don't be surprised if we have more Intel in our future or ARM.

</comment></comment></comment></comment><comment><USER19> > Notably, Intel is not inside.

I can hear the loud silence of that full stop.

</comment><comment><USER20> Now i wonder if these were considered/known

[https://www.servethehome.com/ampere-altra-80-arm-cores- for-c...](https://www.servethehome.com/ampere-altra-80-arm-cores-for-cloud/)

</comment><comment><USER21> I'm a big fan of CloudFlare. I own a little stock, and I moved our company over to it after running on a competitor for about a year. CloudFlare has been much better. Whenever I use the front end, it just feels like it's made by people who actually need to use this stuff, and it is so straightforward. The api is great too. When we were with the competition it was ridiculous how often we had to have an engineer assist us with setup because the front end didn't support some feature we needed. With CF we signed up one day and have never had to have manual changes made by support, and the health checks, load balancing and failover have worked from day one. With the competitor the health check story did not live up to the reality and we had several outages related to the failover system not recovering properly.

When they publish these blog posts, it shows to me that they are willing to consider bold moves and that they aren't afraid to be different. Also, that their architecture has been designed with this agility in mind. I've visited their offices and while their corporate culture didn't seem like the best fit for me, I liked the team and what they are doing.

<comment><USER22> "it shows to me that they are willing to consider bold moves and that they aren't afraid to be different"

Because they benchmarked a drop-in-place commodity replacement as being a better performance-per-dollar for their operation? I'm not sure what's bold about that. I find the notion that they posted a blog entry about this pretty bizarre -- almost rinky-dink. It seems like it's pandering to the AMD fanbase (which I am right now, just as anyone who is paying attention is, but I can still recognize it)

EDIT: Sorry, I didn't realize I stepped into a Cloudflare circlejerk. Apologies and carry on. So brave!

<comment><USER23> There's a ton, just a ton of intel-specific integrations and Cloudflare's switch to AMD was not just a "drop-in-place" move.

<comment><USER22> What "intel-specific integrations"? Cloudflare specifically talks about how they keep their stack runnable across a wide-range of platforms, including even entirely different instruction sets (e.g. ARM). Their own words support my statement.

I'm pretty sure it was a "drop-in place" move, and they say absolutely nothing to the contrary. They benchmarked a system that performed better than their existing system for whatever criteria they targeted, and chose it. Story at 11. Saying they "abandoned" Intel is uproarious given that if Intel pushes out a new 128-core Xeon at a decent price, they'd as easily "abandon" AMD for Intel.

<comment><AUTHOR> As I say in another comment... AMD makes sense for us today because of the performance per watt. We continue to keep our software ARM-ready and look at ARM-based solutions. We also continue to look at Intel. We'll use what gives us the best requests per watt.

But it is notable that these are our first servers wit NO Intel components at all.

<comment><USER24> I'm curious why requests per watt is an important metric?

Are you running up against some sort of heat limit or optimizing for electricity cost?

Seems like requests per amortized dollar all in would make more sense. Or requests per cubic foot of data center space if that is your limitation.

<comment><USER14> This is a good question and I would like to learn the answer too.

According to some napkin calculations, the CPU is $5000 and will be kept in service, I guess, 5 years.

The US average price is 13 cents / kWh so this 225 watts CPU will cost $1280 in electricity over those 5 years.

Colocation price is probably low, let's say $50 / 1U server / month. So that's another $3000.

Why is electricity the most important here? I guess because you can't lower the other 2 costs very much? But isn't the CPU price itself based on the power savings it does provide?

<comment><USER25> Data center space is generally plentiful. Power and cooling, which for most purposes can be considered equivalent, are the scarce resource.

CloudFlare is trading half their server density[0] for a ~25% gain in performance-per-watt and performance-per-node[1]. Power is the whole ball-game at scale.

[0] [https://blog.cloudflare.com/a-tour-inside- cloudflares-g9-ser...](https://blog.cloudflare.com/a-tour-inside- cloudflares-g9-servers/)

[1] [https://blog.cloudflare.com/an-epyc-trip-to-rome-amd-is- clou...](https://blog.cloudflare.com/an-epyc-trip-to-rome-amd-is- cloudflares-10th-generation-edge-server-cpu/)

<comment><USER14> Ah, so it's not about power being a big expense, but being a constraint that is limiting their growth:

> We are constrained by the data centers' power infrastructure which, along > with our selected power distribution units, leads us to power cap for each > server rack.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> Title is "Technical Details of Why Cloudflare Chose AMD EPYC for Gen X Servers"

<comment><USER27> Blog post is by Nitin Rao, Head of Global Infrastructure at Cloudflare.

Submission and editorialized title change is by John Graham-Cumming, CTO at Cloudflare.

Not sure what to make of that.

<comment><USER28> jgrahamc is more active on HN, and he seems to keep tabs on all Cloudflare discussions and answers questions when asked. Don't see what's odd about it. Haven't noticed Nitin here.

<comment><USER29> It's not odd that he submitted it. It's odd that he changed the title, given the HN guidelines against changing titles.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment></comment></comment></comment><comment><USER30> Let's put it this way.

I'd rather program single core applications on my i5-4690k than any other ryzen series chips including threadrippers with 12+ cores.

I have used two threadrippers for more than 6 months.

Linux still runs faster on i5-4690k which is 6 years old

<comment><USER31> Odd, I switched from that processor to the AMD 2700 last month and I'm enjoying the legroom.</comment></comment>


Uber pulls self-driving cars after first fatal crash of autonomous vehicle - <AUTHOR> http://money.cnn.com/2018/03/19/technology/uber-autonomous-car-fatal-crash/index.html <comment><USER2> [https://news.ycombinator.com/item?id=16619917](https://news.ycombinator.com/item?id=16619917)

1400+ points</comment>


How to win friends and influence people? - <AUTHOR>

Hi guys,<p>after read this amazing book "How to win friends and influence people" I was wondering how to leverage people-skills.
 Anyone knows some kind of technique, metodology or even a software (CRM for personal use) which could support the Carnegie's advices? <comment><USER2> You would have to create your own personal system. Since people may have multiple skills, and skills only relevant to yourself.

Although, if you read "Never Eat Alone" to provides a good framework to build from.

<comment><AUTHOR> I'll try it.. Tnx!</comment></comment>


SUVs double pedestrians' risk of death (2003) - <AUTHOR> https://www.newscientist.com/article/dn4462-suvs-double-pedestrians-risk-of-death/ <comment><USER2> FTA:

>>A pedestrian struck by a large van is three times as likely to die as someone hit by a car at the same speed. Pedestrians struck by large SUVs are twice as likely to die.

So why is the article title not "Large vans triple pedestrians' risk of death"?

<comment><USER3> Probably because ~nobody especially cares about large vans. The SUV, on the other hand, is a cultural icon that represents middle-class prosperity and rugged individualism.

</comment></comment><comment><USER4> SUV's are also a fair bit safer for the occupant, especially in side-on collisions at higher speeds where someone in a sedan might end up with a bumper through their temple VS a SUV driver who might just lose a leg.

</comment><comment><USER5> [2003]

<comment><AUTHOR> edited, thanks</comment></comment>


Tumblr suffering extended downtime, now out of action for almost 2 hours - <AUTHOR> http://thenextweb.com/insider/2012/10/26/tumblr-is-down-staff-working-quickly-to-restore-performance/

<comment><USER2> Well the "Find out why" page that is linked from the down page is also down.

[http://www.tumblr.com/docs/en/error_troubleshooting#service_...](http://www.tumblr.com/docs/en/error_troubleshooting#service_is_temporarily_unavailable)

</comment><comment><USER3> Youtube also? <http://downrightnow.com/youtube>

</comment><comment><USER4> This is incredibly annoying. I didn't realise how much I replied on Tumblr. I was trying to get the contact email for a few people for my YC application and they all have tumblr site's, I do too. Luckily Google has a cache.</comment>