Show HN: Userfox (YC S11) — Better Welcome Emails  - <AUTHOR> http://userfox.com

<comment><AUTHOR> we built _a lot_ of stuff for userfox over the past few months. and we were looking at it all, making sure the user interface was usable, and so on: and ultimately decided that actually: sending emails _when a user signs up_ is one of the most valuable inflection points, because:

a) it applies to _every_ user (= highest ROI on copy written)

b) first impressions matter!

and c) its minimal work / thought for our customers. maximum value.

so we decided screw it! lets ship something this week! this month! and here we are. lets do one thing really well.

so userfox today allows you to send a drip sequence of emails to your new users. you can choose the days, the subjects, the content, we support your custom email theme, we even show you clicks and conversions, and so on.

it's _awesome_ because its so light and easy. we're going to roll out some awesome custom data features very shortly. dead simple things, like simply "send this welcome email unless a user is on a paid plan."

et voila. when i look at products, i look at what they require me to do, and what they give me in return. i think that userfox can move the needle on your business, and to do that we ask for literally 15 or 30 minutes of your time. i'd bet you'll see more impact from userfox than your sophisticated SEO strategy in fact.

i have been on hacker news for a long time: it maybe even helped me get into ycombinator! but these are all stories for another day: right now, i wanted to show hacker news our product, because i think if you're a bootstrapping business: userfox is a no brainer. "it just works."

<comment><USER2> Nice, we built something similar internally (but without the nice frontend and relying on sendgrid for analytics etc).

What's missing in the longer term are more detailed ways of bucketing your customers based on where they are with the product, ie: did they deploy/install/upload a picture/whatever other functionality you offer. But as you've said, shipping it is important.

Another pain point you guys addressed was that making custom table based html templates for email is a pain. If you'd offer more templates in the future, that would be a nice thing to add.

<comment><AUTHOR> We'll offer bucketing. It just seems very hard to do right: now from a software nor even design point of view, but in a manner that makes it worthy of a time investment for young startups. welcome sequence felt like the low hanging fruit. but it _is_ coming.

We actually had custom themes. My co-founder will mock me for now removing them. ("simple is best!! these are UGLY!! People will want a clean simple theme or custom HTML. REMOVE THEM.")

shoot me an email though and i'll get my designer to build you (or anyone else) a custom html theme. (surprise bjoern!) firstname.lastname@example.com

</comment></comment></comment><comment><USER3> Congrats on launching - looks great! My issues that prevent me from signing up would be:

1) No pricing structure means that I question whether you'll be in business in a year, or if you are in business, that you're service will be wayyyyy different then (will you insert ads into my emails? will you sell my info to a 3rd party? etc). These are questions you cannot answer today - you just can't. You can say, "Oh no, Scott - we would never do those things!" But no one will believe you b/c you haven't been around long enough.

2) My even bigger "beef" with this is that, because you have no track record, you cannot estimate your delivery rate. A big reason to go with the big email companies is b/c they can offer a high rate of guaranteed delivery. Your delivery rate will, in large part, be out of your hands - it's in the hands of your customers' content/emails. How will you protect yourself (and thus your customers) from bad customers who buy lists and use you to spam the lists? How will you vett your signups? What's your policies on when you would terminate a customer for spam?

All in all, email is too critical to trust to a fresh startup IMO. I wish you luck and, if you guys are still around in a few years and have answered the above questions, I may become a customer!

</comment><comment><USER4> The sign up button says "try for free", which implies it's a trial signup. But I can't find the price for the subscription anywhere on the website.

<comment><AUTHOR> It is free for now. There'll be pricing eventually, but it'll be for additional features (such as a/b testing and so on) as we ship them.

Right now, if you sign up, it's free to use, and we'd never be like, "hey man, you now owe us money for stuff that you thought was free."

<comment><USER5> I've avoided signing up because I couldn't find a price.

Just saying its free / there is no pricing plans yet etc would have let me sign up, or an actual pricing list.

I won't try a service without knowing whether I can actually use it going forward (I'm time poor) so the lack of pricing information anywhere makes me leave the page.

<comment><USER6> I'll second this. I was interested, but it's not something we can evaluate until you're ready to commit to price bounds.

Given the heat in this space now, it would also be nice to know how your service differs from e.g. Vero or customer.io.

</comment></comment></comment></comment><comment><USER7> Looks pretty cool. One question - pricing? There's a "try for free" button, but there's no indication of how long the trial actually lasts nor of what happens after the trial. Note that I didn't sign up, - this information is only from the home and signup pages - but it would be great if I (or any potential customer) could see this info right up front.

<comment><AUTHOR> Pricing will be for new, more sophisticated features, what you see today will always be free. Features like push notifications, a/b testing, custom campaigns, additional email themes, and so on.

I have learnt a lot from patio11 so we'll always be generous and honest about this stuff. Pricing simply didn't feel like a reason to delay launch!

<comment><USER7> Thanks for your reply - definitely looks cool. As I mentioned above (under @jd's post), it might help to change the call to action text...

</comment></comment></comment><comment><USER8> Would there be any reason to use this over, say, a Mailchimp auto-responder? I don't mean that at all in a snarky way, just curious. I'd be interested to give this a go, but can't quite justify shifting my auto-reponders from Mailchimp just yet...

<comment><AUTHOR> If you're starting today: userfox is much faster to get integrated and sending email than MailChimp (or anything else.)

If you're already using MailChimp: send me a note and I'll show you our beta "variables" feature that allows you to say things like "send this welcome email unless this_custom_data equals that." launching soon.

</comment></comment><comment><USER9> I couldn't find a Privacy Policy or ToS anywhere...this is really interesting to me, but if I'm going to let you track everything my users do on my site, I'm going to need to know that you're not going to sell their emails, sell that data...

<comment><AUTHOR> Oops. My heart just missed a beat that we forgot to add this for launch! We're not going to do any bad stuff, we're not going to sell the data nor emails, there is nothing weird going on here, we want to be as useful and valuable for businesses as Olark is. We're a Y Combinator company, and are thusly obsessed about doing the right thing and delivering an awesome product and support.

I'll get a Privacy Policy online asap.

</comment></comment><comment><USER10> This looks really cool and is something I'd definitely be interested in (been on the 'todo' list for too long)... but I really need more info to decide if I want to invest the time in trying it out.

Some kind of 'how it works' page ... how does information get from my app into yours, can I embed per-user links (for example for email confirmation), how do opt-out notifications get back from your app to mine, etc.

Minor UI issue ... the mouse pointer & hover action suggests that the day icons on the front page do something ... but they don't for me (Chrome 22, Windows)

<comment><AUTHOR> I'll answer your questions here and then think about how to answer them on the site.

Q: how does information get from my app into yours

A: async javascript snippet. my co-founder has the scars to prove it is robust.

Q: can I embed per-user links

A: yep. our docs are a lot more elaborate than our user interface at this point, but you can do almost anything you desire. best to shoot me an email and i'll explain. firstname.lastname@example.com

Q: how do opt-out notifications get back from your app to mine

A: we have a simple unsub API to communicate who has unsub'd, we handle the entire unsub from userfox emails obviously. you're going to eventually (soon) send all emails via userfox though.

Thanks for the note on the ui issue. we'll get it fixed.

</comment></comment><comment><USER11> Interesting idea! However from what I have seen, to truly engage your customers through email, it either needs to be personalized, be intelligent enough to track current activity and engagement levels of users and tailor the mails you send accordingly, or .. something else?

It would be nice to hear just out of curiosity what kind of market (low number of important customers or high number of users or both) you are targeting, and what is your strategy on a higher level to increase conversions?

<comment><AUTHOR> Introduce your product through a series of emails.

Two huge benefits over what you do today (almost certainly a singular welcome email)

* helps users understand your product

* reminds users of your product. What was the last product you signed up for? Unless it was userfox, you've forgotten!

Introduce features, tell the story of why you're building what you're building, and so on. I love emails that profile power users. Real explicit actionable advice.

I totally agree you should write specific emails about specific features. We'll support that, but right now you'll make more money by sending a few welcome emails rather than just one.

</comment></comment><comment><USER12> The landing page is quite nice, but the zoom animation and the pointer cursors on the days really makes them look like clickable buttons that simply aren't working.

<comment><USER13> thanks! I actually wanted to remove the pointer/cursor but forgot. Will update this shortly.

</comment></comment><comment><USER14> This is great! I like how you provide some basic advice below the email composition, since many users won't know exactly what to send. I'd even suggest you could build on that with some more specific guidelines on sending the 1st, 2nd, 3rd, etc. And guidelines on determining how many to send, when to send, etc, since those things can be edited by users.

<comment><AUTHOR> We actually have a copywriter on team who would _love_ to assist people writing emails. He manages a copywriting helpdesk for our customers, and also offers services to write and manage content. Shoot me an email if this is interesting to you. He writes dozens of emails with tremendous results for some of our customers. email@example.com

<comment><USER14> Thanks! I've set it up now. One question about the embed code is what happens if I don't have the user's email, or there's no user. If I just say email: "", will that work OK? (ie do nothing.)

<comment><AUTHOR> It'll do nothing. I personally wrap the userfox snippet on userfox.com (uh) with a check to see if the user is logged in, but yours will work.

</comment></comment></comment></comment><comment><USER15> I like it! My main concern is that it's Javascript only. Hopefully I'm wrong, but I can't see anything the code from arbitrarily being inserted elsewhere with my client ID but random email addresses and sign up dates, and thus triggering emails in my name to go to these email addresses that aren't actually my users.

<comment><AUTHOR> we have an even more secure mode that we roll out to customers at volume; naturally anyone can have it, but we're still working out the user interface for it. if this is what is holding you back, email me and you can have the docs. firstname.lastname@example.com

</comment></comment><comment><USER16> I bounced after getting to the form.. As a developer and therefore your main target for potential customers, you never answered the most important question... how? How does it integrate? Is it an API, do you have plugins for my platform? Etc, etc.

</comment><comment><USER17> I've been looking for something like this for a long time. It's something I wouldn't purposely implement because it's a pain to manage time/writing cron jobs, etc.

Love the landing page too!

</comment><comment><USER18> If I remember right there was a paid service around here that did the same thing. You are going to put them out of business. Great product!

<comment><AUTHOR> We'll put them out of business with a superior product. :)

userfox will be freemium business. (what you see now will be free, though.)

</comment></comment><comment><USER19> This is really going to be tough for me over the next two weeks because I'll have a lot of new services to become a power user on.

<comment><AUTHOR> You (probably) jest but I would have loved LinkedIn and Twitter MUCH faster had they done a better job at on boarding me. I didn't get what they were for way too long. Needed a story.

</comment></comment><comment><AUTHOR> who edited the title of this submission? thanks for using the proper em dash, but userfox is supposed to be lowercase.

</comment><comment><USER20> Nitpick - <http://userfox.com/about/> 404s.

<comment><AUTHOR> will update the link. good spot. the correct link is <http://www.userfox.com/about/>

sorry it isn't more exciting. I'll make it cool tomorrow.

</comment></comment><comment><USER21> You know what sounds like a great way to delight users? _Don't_ send me email. Leave me alone. I signed up for your service, not for a newsletter.

<comment><USER22> That is you, but others convert

</comment></comment><comment><USER23> it's like the next evolution of landing page signups. to me this was missing from sites like launchrock.

<comment><AUTHOR> We announced userfox with a launchrock page and I really wish I could have tied launchrock into userfox: sending a drip sequence to users that registered interest in a service would have improved launchrock 100x fold. (as asked, but alas, they're busy.)

</comment></comment><comment><USER24> what are some comparative products, and how does userfox set itself apart?

<comment><USER22> aweber.com currently owns the IM world. I have some experience with them and with mailchimp. This is like somewhere in between, aweber is more spammy prone while mailchimp won't allow you to auto-respond unless you buy a subscription.

Baisically, there isn't a reliable freemium service with an autoresponder. It also strucks me as "hassle free" light service i would use for medium to small size projects. Will use it soon</comment></comment>


Titch's OG Xbox mod: IDE-SDHC, PSU swap, softmod, and more - <AUTHOR> http://forum.arcadecontrols.com/index.php?topic=163244.0 <comment><AUTHOR> These mods are so much fun, and easy enough for determined kids, or adults. Takes me back to my MechAssault softmod OG Xbox, in which I replaced the dashboard with XBMC (now commonly known as _Kodi_ , yes that Kodi[1]), and had to setup ftp to do most of that and the rest, including dumping my OG HDD encryption keys to replace the drive, hot plugging the OG optical drive to dump the firmware for that and patch it, re-assemble, and then add my network shares for network attached saves, game backups, etc.

I almost forgot the part where I had to splice a USB extension cord to an Xbox controller extension cord, twice. Once to format the USB stick as an Xbox memory stick, and the other direction to transfer the MechAssault game save exploit to the Xbox-formatted flash drive with some Game Genie type software that is "free with purchase of the hardware" which you just made at home from spare parts.

Xbox controllers and memory cards have been USB devices since forever. That's a neat quirk, and potential exploitation vector. Lots of legacy code and edge cases, the specs (which one you want lol) are pretty dense reading. People make mistakes. Be safe while modding, on that note!

[1] [https://en.wikipedia.org/wiki/Kodi_(software)](https://en.wikipedia.org/wiki/Kodi_\(software\))</comment>


Every important person in BitCoin just got subpoenaed by NY financial regulators - <AUTHOR> http://www.forbes.com/sites/kashmirhill/2013/08/12/every-important-person-in-bitcoin-just-got-subpoenaed-by-new-yorks-financial-regulator/ <comment><USER2> Unpopular opinion of the day: bitcoin is real money, and the government _will_ regulate it and control it as such.

In my opinion, the end-game is this: bitcoin addresses are taxable, with occasional tax agents spot-checking large accumulations of bitcoin to determine if said addresses fall within their jurisdiction. Bitcoin has the unusual ability to have a very tight trace on where a given virtual coin goes: that just makes the ability to watch the money easier.

<comment><USER3> A bitcoin address is just a container for some amount of BTC. Holding an amount of currency isn't taxable, and exchanging currency often isn't taxable either. (I'm generalizing across jurisdictions, but I think what I'm saying is true for most of them.)

If you move money from one pocket to another, or one savings account to another (that you own), that's not taxable. Very many transfers between bitcoin addresses is just like that: the 'change' from a transfer goes to a new address owned by the same person.

Even when the addresses are owned by two different people, the transfer often isn't taxable. You don't pay a tax when you pay a bill, but that's a currency transfer between two parties. Even when you buy something it isn't necessarily taxable; in many jurisdictions many products are sold tax-free based on either the type of product or where the buyer and/or seller are based.

I don't think there's a way to enforce taxation on bitcoin that's not already being used to enforce cash sales taxes and cash income, despite the tracability of the coins, because the address owners may not be identifiable, and the nature of the transfer is definitely not identifiable from the blockchain.

<comment><USER4> In Canada, even if you destroy all paperwork and tell the taxman that you don't remember anything, the law permits them to look at your assets and decide how much you owe. Then it's your burden to prove otherwise. Is it different in the US? Hell they could even force exchanges or code mainteners to build in a tax system.

<comment><USER5> Nobody can force opensource code maintainers to build anything. More importantly, nobody can force all exchanges to run any particular code; exchanges can exist in any political jurisdiction.

<comment><USER6> Whilst way you say may technically be true, the government could just declare this:

Each person must publicly declare the bitcoin addresses that they hold. Any legitimate business accepting payment in bitcoins can only receive bitcoins from other registered addresses, else they are black flagged and no longer a registered address.

Now, your average business and the banks are not going to circumvent these rules. The Banks will probably give their business customers payment gateways that enforce these rules without the business having any choice. Black market bitcoins will still exist, they will just be useless as "normal" currency and will be completely separate, with no way to cross over. Since all transactions are public it is trivial for the government to enforce these rules.

You'll still be able to run your exchange in some other political jurisdiction, but unless the Government white lists your addresses, nobody will be able to spend those coins on legitimate businesses in your country.

<comment><USER7> _> Any legitimate business accepting payment in bitcoins can only receive bitcoins from other registered addresses, else they are black flagged and no longer a registered address._

This particular implementation wouldn't actually work. Anyone can send BTC to any address, so it would be easy to poison the well.

(But I suspect some similar scheme could be feasible. You might be able to enforce the rule on BTC->$ withdrawls? I wonder about mixers, though.)

<comment><USER6> _This particular implementation wouldn 't actually work. Anyone can send BTC to any address, so it would be easy to poison the well._

You could easily have software that would automatically turn over to the government any coins sent from addresses that are not registered. It's like if you found a briefcase full of money: you'd turn it over to the police (or maybe you wouldn't, but that's what you _should_ do). With software, it could just be automatic.

If you refuse to run software that does this, or you don't turn over coins received from blacklisted sources within some period of time, you get blacklisted.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Finally - New York is going after financial criminals! Oh wait a minute...

In related news last Friday the Justice Department had to admit that the success numbers Eric Holder trumpeted on mortgage fraud were massive overstated - by 80 percent. _The government restated the statistics because it got caught red-handed by a couple of nosy reporters._ Priorities...

[1] [http://www.bloomberg.com/news/2013-08-11/eric-holder-owes- th...](http://www.bloomberg.com/news/2013-08-11/eric-holder-owes-the-american- people-an-apology.html)

</comment><comment><USER9> Well, my own submission just got [dead]ed --no indication as to why-- but I'll paste my comment here as well:

I know very little about Bitcoin or money transmission laws. Unlike other currencies it does not seem to have fundamental dependence on any centralized arbiter, though the practicalities of large exchanges like Mt. Gox seem apparent to me. That lack of dependence on a Fed-like body appears to me like its biggest advantage, above any other potential for anonymous payment and laundering. I'd like to know what exactly is entailed in becoming compliant with money transmitting and laundering regulations and whether Bitcoin in its current form could become effectively compliant. Is that even a meaningful concept, or does the structure of Bitcoin fundamentally preclude coming into effective compliance?

[dead]ed submission: [https://news.ycombinator.com/item?id=6201643](https://news.ycombinator.com/item?id=6201643)

<comment><USER10> > whether Bitcoin in its current form could become effectively compliant

Why couldn't it be? The entire transaction history of a wallet is preserved into the future. As soon as you correlate a BitCoin wallet with a person, you have their entire history with that wallet. It seems more like a government's wet dream than anything else.

<comment><USER11> ehm, no. you can create brand new wallet for each transaction and wallet on its own is not connected to your real identity in any way. it's more like government's worst nightmare.

<comment><USER12> As I understand it, if you want to receive bitcoins with wallet A and send those same bitcoins with wallet B, you would need to transfer said bitcoins from wallet A to B. And each transfer is recorded in the blockchain.

<comment><USER13> This is correct. However, it is difficult to prove that A and B (or perhaps every wallet in some long chain) are owned by the same person, especially if everyone has a large number of wallets and doesn't reuse them when they are empty.

Let's say the blockcoin shows a transfer of 1 BTC to a new wallet A, and then to a new wallet B, and then from B to a wallet owned by a registered BTC-USD exchange C; to comply with government regulations and protect themselves against fraud, C checks the ID of the owner of the wallet B. A government can now determine the identity of B (and might even force C to provide the information on all transactions in real time, so they know who B is even without an investigation), but they cannot automatically infer the identity of A. There are two possibilities: Perhaps A is owned by a different person, who earned BitCoin for doing some work, and then purchased another service from B. Or perhaps A and B are owned by the same person.

In reality, this might not be the only piece of information available, and governments will probably want to use statistical techniques to estimate the probability that a particular address is owned by a particular person, combining all evidence. They will likely take into account all points where money comes into or leaves a wallet with known identity (e.g. in USD -> BTC transactions or BTC -> USD transactions), and the structure of the network between those transactions. For example, suppose wallet A, B, and C are known to be owned by the same person, and someone moves money from all those wallets into wallet D. Then governments will probably infer that D is owned, with high probability, by the same person as wallet D (because multiple low probability pieces of evidence can combine to give a higher probability). Of course, the transactions are not independent, because the owner of A, B, and C might just be a regular customer of D - timing evidence might be taken into account, along with other evidence about the identity of D (for example, does D only receive money from the owner of A, B, and C, or from other sources? Where does the money go after that)?

<comment><USER14> > but they cannot automatically infer the identity of A.

They can certainly walk up the tree though, which is impossible with cash but extraordinarily easy with BTC. In this case B could have a tax bill to pay unless they can prove otherwise.

</comment></comment></comment></comment></comment></comment><comment><USER15> This is just the tip of the iceberg. Of course the government cares about money, and of course it wants to control the money supply. And, as a consequence, the USA will never allow any major currency inside its borders other than the US dollar.

The history of the United States is littered with the fights over who gets to determine what is money and how much of it there is: Hamilton's fight with Jefferson and Madison over the need for a central bank, Jackson during his run for the Presidency denouncing the central bank--and this becoming the main issue in the campaign, the popularity of Williams Jenning Bryan (cf. the famous "Cross of Gold" speech), etc. etc. all the way up to the horrible stagflation of the 1970s ("Whip Inflation Now!") and the recession caused by the ultimately successful efforts by Fed Chairman Paul Volcker's to end it. It is reasonable to believe--and certainly most people in the US government believe--that control of The Money is control of the economy.

Why would any successful government ever voluntarily give up that control?

<comment><USER16> I pretty much agree with what you are saying : Governments (and central banks) would never voluntarily give up the control they have now, especially when a currency is being exchanged for one they have control over.

It is also interesting because bitcoin may be influenced by governments, but not issued by them nor central banks, which is already a fundamental difference in the battles that have come before.

The amount of time/resources that will be spent to try to control something that was never in their control (like kind of along the same lines as government measures in Argentina), nor under the control of any single entity for that matter, will be extremely telling. As far as I'm concerned the writing is on the wall… what is going on now is just the ongoing manifestation of what is to come next.

Not to mention that as more bitcoins are used/accepted by people in exchange for goods/services between individuals, governments will be and are increasingly being side stepped. It will be interesting to see this dynamic unfold more in places where (local) governments are becoming insolvent.

Bitcoin is in no position to supplant the USD, EUR, JPY, GBP, RNB etc, because bitcoin operates in between them now. And as more people loose faith in their respective currencies but still want ways to exchange between other individuals for goods/services, bitcoin will increasingly operate as well in a realm of its own.

</comment></comment><comment><USER17> Looks like this might be the least of BitCoin's government problems. Check out this appropriations bill currently before congress; [http://beta.congress.gov/congressional-report/113th- congress...](http://beta.congress.gov/congressional-report/113th- congress/house-report/171/1) Search for BitCoin in the text and you get the following gem...

"Money laundering.--The Committee understands that Bitcoins and other forms of peer-to-peer digital currency are a potential means for criminal, terrorist or other illegal organizations and individuals to illegally launder and transfer money. News reports indicate that Bitcoins may have been used to help finance the flight and activity of fugitives. The Committee directs the FBI, in consultation with the Department and other Federal partners, to provide a briefing no later 120 days after the enactment of this Act on the nature and scale of the risk posed by such ersatz currency, both in financing illegal enterprises and in undermining financial institutions. The briefing should describe the FBI efforts in the context of a coordinated Federal response to this challenge, and identify staffing and other resources devoted to this effort."

Talk about a prejudiced statement. Time to call your congress person.

<comment><USER18> This is not prejudiced at all. All it states, is that the committee UNDERSTANDS that cryptocurencies have the POTENTIAL to be used for money laundering, etc. It is true, it can be used, and is used for those means.

<comment><USER17> Did you read the whole thing? They call it an 'ersatz' currency. Look up the word ersatz it has pretty negative connotations it's hardly a neutral statement.

</comment></comment></comment><comment><USER19> This worries me more about other virtual currencies (eg. "game" money) than it does about Bitcoin. The last time something like this happened because of Bitcoin (FinCEN), Linden Lab forced the closure of all third-party Linden$ exchanges [1] to cover itself legally. Those were very scary times for everyone involved in Second Life.

As someone who does business in Linden$ et al, I (selfishly) wish the media hype around Bitcoin would simmer down, lest my own life become a lot more complicated. The way these government announcements always refer to cracking down on "virtual currencies" in general is very disconcerting, especially when the term is so hazily defined.

[1] [http://blog.nalates.net/2013/05/08/end-of-linden- exchanges/](http://blog.nalates.net/2013/05/08/end-of-linden-exchanges/)

</comment><comment><USER17> "the department says it wants to make sure Bitcoin company customers' funds are "safe and sound," expressing concern about consumer complaints "about how quickly virtual currency transactions are processed.""

So, are they saying there are complaints that the transactions are processed too _quickly_? Because I've never had a BitCoin transaction take more than an hour or so to complete where as my regular bank routinely takes about 3 business days. Makes you wonder what their motivations are.

<comment><USER20> It's doublespeak for we are taking an interest in this burgeoning opportunity and will likely be adding requirements to exchanges that will help to limit fraud, and ensure that the government gets whatever tax revenue they are obligated.

Frankly, I see it as the powerful interests (banks/gov) taking their first step to assert their control of the new market.

Someone less pessimistic may feel this is a good measure to ensure that something good will stay good by helping to keep fraud out of this new system.

</comment></comment><comment><USER21> Explain why not a single banker has gone to prison from both the fraudulent foreclosure crisis and the 2008 wider banking crisis yet these fools all of a sudden want to regulate BTC?

They can't even regulate the US dollar.

</comment><comment><USER22> Coincidentally today:

Crypto-currency for NSA leaker: Snowden fund accepts Bitcoin

Published time: August 12, 2013 14:51

US fugitive Edward Snowden's defense fund, launched recently by WikiLeaks to raise money for the legal protection of the NSA leaker, has announced it now accepts donations in virtual currency Bitcoin.

[http://rt.com/news/bitcoin-snowden-fund- wikileaks-384/](http://rt.com/news/bitcoin-snowden-fund-wikileaks-384/)

</comment><comment><USER23> Other unpopular opinion of the day: Ron Paul was right about competing currencies being infringed on.

</comment><comment><USER24> Good to know that _none_ of the technical people or authors of the software are important as far as NY is concerned! :P

</comment><comment><USER25> Looks like the price of Bitcoins just made a good jump at [https://www.mtgox.com/](https://www.mtgox.com/) . Are speculants thinking that if the us government are geting involved it validates Bitcoin further?

Edit: Screenshot of the jump: [http://i.imgur.com/G5Dk7Nh.png](http://i.imgur.com/G5Dk7Nh.png)

<comment><USER26> possibly also something more along the lines of 'anything that keeps bitcoin in the news is good news', keeping up the influx of new people wanting to try bitcoin.

</comment></comment><comment><USER27> The issue of bitcoins vs IRS combined with the recent news about the NSA actually scares me. Why does the Gov feel the need to control us?

</comment><comment><USER28> Based on the title, I was hoping Satoshi Nakamoto had been subpoenaed.

<comment><USER29> Maybe he's just dodging the process server.

</comment></comment><comment><USER30> In the end the Federal reserve will protect their monopoly on money. The more legitimate Bitcoin becomes, the more likely a target of Fed action.

</comment><comment><USER31> Was interested to see how many posts were going to discuss the possibility of ban following Thailand. Not One.

Is this not a real and probably outcome?

<comment><USER32> It wasn't banned in Thailand.

</comment></comment><comment><USER33> First they ignore you, then they laugh at you, then they fight you, then you win.</comment>


Breakthrough narrows intelligent life search in Milky Way - <AUTHOR> https://phys.org/news/2020-09-breakthrough-narrows-intelligent-life-milky.html <comment><AUTHOR> >Extending the Breakthrough Listen nearby star survey to other stellar objects in the field

[https://arxiv.org/pdf/2006.09756.pdf](https://arxiv.org/pdf/2006.09756.pdf)</comment>


Revere launches with $2M in funding to sell workout drinks made from plants - <AUTHOR> https://techcrunch.com/2017/07/12/revere-launches-with-2m-in-funding-to-sell-workout-drinks-made-from-plants <comment><USER2> so juice.</comment>


Feds to look at Apple policy on programming tools - <AUTHOR> http://finance.yahoo.com/news/Feds-to-look-at-Apple-policy-apf-2612393474.html?x=0&.v=6

<comment><USER2> Is everyone quoting the same "person with knowledge of the inquiry"? Or are they quoting others who are writing up about this person?

I'd laugh quite a bit if this whole chain of antitrust articles turns out to have been generated from a barroom speculation...</comment>


mcxNow crypto currency exchange is shutting down for a period of time - <AUTHOR> https://mcxnow.com/?shutdown

<comment><AUTHOR> This is really sad, because it was the leanest and the meanest exchange out there. Not to mention the incentives.</comment>


Technical preview of Kubuntu Linux ISO with KDE Plasma 5.0 - <AUTHOR> http://kshadeslayer.wordpress.com/2014/07/28/plasma5-now-more-awesome-as-a-kubuntu-iso/

<comment><USER2> More informative link with actual videos:

[http://kde.org/announcements/plasma5.0/](http://kde.org/announcements/plasma5.0/)

</comment><comment><USER3> Blog author here, let me know if you have questions! :D

<comment><USER4> Hi, thanks for your efforts. Is it 64 bit or 32 bit? Can't use 32 bit isos, stuck with 64 bit only UEFI system :(

How about a 64 bit (working :P ) kubuntu-active iso as well?

<comment><USER3> This is a 64 bit ISO, I reckon I should clarify that in the naming, I'll fix it with the next ISO's , please do let me know how it goes with EFI systems, we're planning on moving the ISO building infrastructure to the same one as Ubuntu, so we'll get full EFI support as soon as that happens ( in a few weeks I guess )

</comment></comment></comment><comment><USER5> shadeslayer, how about a PPA for testing Plasma 5 in Kubuntu 14.04? I'd love to try it, but rebooting seems a great inconvenience :)

<comment><USER3> Sorry, but I don't see that happening since that would involve backporting Qt 5.3 as that is what upstream advises to use with Plasma 5, and backporting Qt5 is a huge hassle and a even bigger hassle to maintain the packages for the lifetime of the 14.04 release. However, fear not! You can try out Neon 5 which is built for Trusty! See [https://techbase.kde.org/Getting_Started/Using_Project_Neon_...](https://techbase.kde.org/Getting_Started/Using_Project_Neon_to_contribute_to_KDE#Using_Project_Neon_5_for_Frameworks_5_Development)</comment></comment>


Data haul by Android Flashlight app 'deceives' millions - <AUTHOR> http://www.bbc.co.uk/news/technology-25258621

<comment><USER2> This has already been extensively discussed here:

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


Persona - Mozilla's decentralized and secure authentication system - <AUTHOR> https://developer.mozilla.org/en-US/docs/Persona

<comment><USER2> Authentication mechanisms and they way they are implemented can have bleedover into the ability of a user to maintain control of their anonymity and privacy.

Has there been any writeup that explains the potential impact of Persona on privacy? Not just the impact when used as intended, but also any unintended effects?

<comment><USER3> I'm not aware of any standalone articles, but something of that nature would be really fantastic. Such an article would probably be best if written by someone outside of the Persona team.

<comment><USER4> Just a further comment, anyone interested in writing such an analysis or document should contact us with any questions!

</comment></comment></comment><comment><USER5> Previous discussion: <http://news.ycombinator.com/item?id=4580986>

</comment><comment><USER6> I can't come up with any reason why this isn't going to be massive. The password problem is the single most frustrating and alienating issue I can think of for normal users.

<comment><USER7> Two big issues so far: it still uses email for password resets (without alternatives that I know of) and it doesn't work without JavaScript. I hope both of them get addressed.

<comment><USER8> The fallback identity provider (at login.persona.org) does use email for password resets, but other identity providers will likely use other mechanisms.

<comment><USER7> I hope so, but why not do the right thing in the default identity provider?

Lately, there have been _tons_ of high-profile hacks that boiled down to taking control of victim's email and resetting passwords to other accounts. What's seems to be the best response possible from web developers? Is it:

a) Demand that all your users use Gmail with enabled two-factor authentication, then smugly blame them for all security issues if they don't.

b) Stop using emails for password resets, since you don't really know how trustworthy your users' email providers are.

<comment><USER9> One of the ways crackers gain access to a user's email is by guessing their password, a simple task when a huge number of users use the same password everywhere. With Persona, only your email provider (and the persona.org fallback) have your password (two passwords in the case of the fallback), hashed or not.

If you're already a password ninja and use a different and unpredictable password on every different site without forgetting them, Persona isn't an improvement in security. If you don't, as most users don't, Persona makes authentication more secure and more user-friendly at the same time.

With Persona, your weakest point would still be your email provider, which is why it would still be wise to recommend two-factor authentication for your email.

If you're already a password ninja and use a different and unpredictable password on every different site without forgetting them, AND you have enabled two-factor authentication with your email provider, Persona IS an improvement in security. This is because, with Persona, having two-factor authentication for your email would automatically mean two-factor authentication for all your websites as well.

<comment><USER10> I use Two-Factor Authentication across a lot of my accounts. I feel a lot more secure when I can telesign into my account. If you have that option available to you use it, it is worth the time and effort to have the confidence that your account won't get hacked and your personal information isn't up for grabs. If you opt into 2FA, you will have to "Confirm your phone". You would receive a text message with a specific code to be entered into the system. If you don't want to do this every single time, you can designate your smartphone, PC, or tablet as a trusted device and they will allow you to telesign in without the text code. Should an attempt to login from an unrecognized device happen, it would not be allowed.

</comment></comment></comment></comment></comment></comment><comment><USER11> How would I log in from a friend's computer with Persona? How about from an Internet cafe; how safe would it be? Persona looks like something that lock's you into a certain device or at least makes it harder to log in on device's that are not your own.

I'd rather they made OpenID less scarry (to average Joe) instead.

<comment><USER12> You really shouldn't login from any non-secure terminal. I have catched even pros doing that mistake with production systems. It's major fail!

<comment><USER11> Major fail or not a good part of the world does not own their own computer.

</comment></comment></comment><comment><USER13> Are there any good descriptions for how Persona works? I can find plenty of developer documentation on this site, but I can't seem to find a good, concise description of what parties are involved and what the protocol is, etc.

(Maybe I'm not looking deep enough? Anyway, thanks in advance.)

<comment><USER8> This talk gets into how the protocol works without getting too much into the crypto: <https://www.youtube.com/watch?v=iZBTc7iEkQY>

<comment><USER7> I just watched the video. So, apparently, the long-term goal is to have email providers to support this and sign user certificates. I'm still not clear on what information a certificate would contain.

More importantly, I really dislike the answer to second question from the audience. Even when the system is fully supported without fallbacks, hacking person's email account will grant the attacker ability to log into all websites as the victim?

I already am quite concerned with how much control over everyone's identities services like Gmail have. If I understand it correctly, Persona will give them more direct control over user's identities. It's only decentralized in a sense that different email providers will be able to implement it separately, and verify identities of _their_ users.

I hope I'm missing something from the big picture here.

<comment><USER9> > If I understand it correctly, Persona will give [identity services like > Gmail] more direct control over user's identities.

No, Gmail already has that control. Almost every website out there allows you to reset your password by sending you an email. If you control the user's email, you can change their passwords. Persona changes nothing in this regard.

<comment><USER7> 1\. Right now, Gmail has only as much control over accounts as individual website developers give it. It's up to us to implement alternative password reset system and make them the default. Any website can (and in my opinion should) switch to something else at any time, because, firstly, password reset system is decoupled from core authentication mechanism and, secondly, it is under web developer's control. Mass adoption of Persona will change this problem from locally solvable to unsolvable. If this becomes _the_ authentication standard (which seems to be the project's goal), you will _have to_ trust user's email provider.

2\. Right now, Gmail can reset your password, but it cannot silently authorize someone else to use your account without you knowing. It seems (and correct me if I'm wrong here), that with Persona such scenarios will become possible.

<comment><USER9> 1\. You're comparing Persona to an imaginary world where most websites don't rely on email providers to prove authentication. I'm comparing Persona with the actual situation where people use the same password everywhere. Persona isn't perfect, but it is much better than what the vast majority of websites use, and it allows even better methods to be implemented where needed. Furthermore, Persona is more usable, and therefore more attractive and more likely to be deployed widely.

2\. Yes, it can. It can delete password reset notifications. If the notification contained the password in plain text, then there would be no easy way to find out whether Gmail logged in to your account on X. If the notification contained a password reset link, there is a possibility that the user would subsequently discover that their password was no longer accepted on X. But given that most users use the same password everywhere, Gmail already has a huge potential for evil, as it could just use the passwords it has already collected. Users that worry about Gmail can use an alternative email provider or their own, after all, email and Persona are both decentralised. Website developers that worry about Gmail can use other authentication methods on top of Persona, such as in-house two-factor authentication.

tldr; if Gmail is evil, both Persona and current systems can't stop it. If that worries you, use your own email server, and use other authentication methods on top of Persona on your websites.

<comment><USER7> _You're comparing Persona to an imaginary world where most websites don't rely on email providers to prove authentication._

I'm comparing hypothetical mass-adoption of Persona with hypothetical mass- adoption of alternative password reset policy. It seems like a fair comparison.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> There was a post about this yesterday, but I'll upvote it because it needs all the exposure it can get.

</comment><comment><USER15> I really like the overall result of Persona when used for logging into a web site, but has anyone come up with a good way of integrating Persona login with mobile apps or APIs?

I suppose mobile apps would ideally use some sort of Persona login service provided by the underlying OS, and until such a thing exists I guess an app could reimplement all the user-agent logic and load the user's login page in a webview. But I have no idea how at all I would go about designing an API for a website which uses Persona for logins.

<comment><USER3> We don't have a good path for native apps, yet. There have been a few experiments using Persona in native iOS (Pancake) and Android (Soup) environments, and it apparently works great in PhoneGap apps, if you use the ChildBrowser plugin.

The bug to watch is this one: <https://github.com/mozilla/browserid/issues/2034> supporting environments without popups will clear the way for good native SDKs.

</comment></comment><comment><USER16> Other than the benefit of using strong crypto under the hood, I'm not sure what benefits this has over a system like openid. It has about the same level of interactional complexity, and at the additional cost of requiring browser support.

If we're going to have browser support anyway, I'd rather just use standard two-way SSL and put the work into developing better UI and private key distribution systems for it. It's even more secure and has a great user experience once you've set up the key in the browser and authorized it to the site.

<comment><USER17> Usability involves more than one target audience: it also has to be easy for developers to integrate.

BrowserID (Persona) took me minutes to implement. On a non-trivial project, it may take a couple hours. The beauty of this _is_ the fact that it still works without built-in browser support. It's designed to be a forwards-compatible API that only becomes more usable with time.

Additionally, email is an excellent way to establish a user's identity, and the fact that it's designed around email makes it easy for a regular person to understand its authentication flow.

The problem with SSL is that it is an all-or-nothing technology. There's a chicken and egg problem: people won't make good UI for it until it's widely used, but people won't use it until it has a good UI. Persona provides an implementation of BrowserID that has a decent UI, and the user experience will only get better with time as more people use it. The chicken/egg problem is solved there, but two-way SSL right now is practically unusable for anyone who isn't very familiar with it (most people). Using an email address is _very_ familiar, though.

<comment><USER14> I've forgone traditional auth in favor of Persona because there are just too many advantages. The user might already have an account, the flow is very good if they don't, it takes literally three minutes to integrate django-browserid (or whatever it's called now) versus skinning quite a few templates for all the login and reset forms, it saves the user from having to remember yet another password, etc etc.

I couldn't be happier with a signin solution. It even complements my legacy solution very well, you can see a demo at <http://www.yourpane.com> (click "Persona", never mind the email field.)

</comment></comment></comment><comment><USER18> Does persona reveal your email address to the website that you login to?

OpenID usually doesn't reveal your email address.

For example, when logging in to Google via OpenID, google will only send back a unique identifier that means 'yes, the user has a google account' but no other personal information. Yahoo does the same.

(of course, it's possible to use OpenID extensions to get a user's email at their discretion)

Does persona work in the same way?

<comment><USER9> Yes, Persona does reveal your email address to the website you log in to. This is considered a feature, because:

1\. It prevents lock-in to Persona. (If you want to migrate away from Persona, you can just send the users an email and introduce the new authentication mechanism.)

2\. Most websites will need some way to contact the user, and will ask for their email address any way.

3\. Users understand the concept of email addresses as identifiers.

If you care about keeping your email address private, you can always use the features your email provider offers such as forwarding email addresses.

</comment></comment><comment><USER19> Just integrated it on a personal Padrino project. Beautifully simple user and developer-side. Congratulations and thanks Mozilla!</comment>


Ask HN: What was the biggest challenge in securing your SaaS/service? - <AUTHOR> By securing I mean building technical security to protect customer / commercially sensitive data, not securing the funding. It would be brilliant to hear both those who did, and those who chose not to care or give up in process. <comment><USER2> I can offer some advice from the other side of the fence as someone who evaluates potential SaaS platforms for use in an enterprise.

Audit log everything. If you think you have enough logging you're likely wrong. I have never seen a platform where I thought "this is nice, but I wish it has less logs"

Strong role based access controls, especially if you provide rights that can be built into custom roles. It's very hard to add these later and I can usually tell when a platform hasn't be designed to handle roles from very early on

Federated logins like SAML or Open ID Connect. Getting authentication right is very hard and it's usually better to use a well tested service rather than try to do it yourself. Codegeek mentioned not storing things you don't need. If you don't need to store passwords you've done yourself a huge favour.

Architecture reviews and penetration tests. Big organizations are going to ask for the results of these processes, so you might as well plan for it. Pen tests are nice, but bringing in outside help to do architecture reviews of your security is really cost effective. You'll catch issues at the design stage where it's still much easier to fix them. Once code is in production security design changes are much, much harder. This is an area you want someone to look over your shoulder to make sure you are considering the right threat models and building things out the right way.

</comment><comment><USER3> Having worked on SaaS products with high demands to security before, and having spent a serious chunk of people's hours on building security infrastructure around it, I'd say the biggest challenges were:

* Identifying threat model (assets we are protecting, what we are protecting them against), that connects to practical business values and risks, not abstract "security ideals". In our case it was understanding what kind of data we're afraid to lose / get tampered with to what extent - for some things we might've lost a license, for other things our CEO might've had a criminal case, so different measures applied.

* Orchestrating practical security with compliance (was relevant for that product, banking -> ISO, PCIDSS and local personal data protection regulation).

* Making hard decisions on whether doing it internally (we've had these competences) or outsourcing some of the implementation work to specialized outfit. Did it internally, was great experience, but would think twice to repeat.

* Making stakeholders understand how much the showstoppers, which emerge along the way, are important to be taken care of.

</comment><comment><USER4> Google 2FA, AWS S3 encryption at rest and its integration with the micro services, ModSecurity integration for Varnish, E2EE for SSL/TLS, infrastructure and micro service security, etc.

I had to build this into Cachoid from day one. No funding and no extra help. I think it boils down to putting oneself in another's shoes and ask: would I use this service myself if it was best-effort work?

</comment><comment><USER5> Security is hard. We all know that. But there are many low hanging fruits that you can do with a little bit of effort. A lot of people ignore even the low hanging ones. I am not an expert but I have a list that I try to follow at the very least:

\- Don't store any sensitive data on your servers unless you absolutely need to. For example, do you really need to store the client's address ? May be not. Think about that. The less the data, the less the risk of exposure.

\- Never trust user input. Always sanitize.

\- Passwords. Please use a one way hash like bcrypt and be done with it. Don't implement your own and never ever do plain text.

\- Offsite backups. Don't store backups on the same server.

\- Learn how to harden your server like adding firewalls, basic security checks using things like iptables/fail2ban etc. Basically, try to keep the bad guys out as much as possible.

\- Check what ports are open on the server. Again, this related to the previous point but don't expose any port that you don't need to. Remember the recent mongodb debacle. Check that things are only running on localhost and not exposed to outside world.

\- Encourage your users to use secure passwords. Don't make up stupid rules like "must have a number". Instead, check if the password is secure enough and then let them save it.

\- For ssh access to server, turn root access off. Create a specific user to handle things. Make ssh key based authentication only and not password based.

\- Subscribe to tech forums where you can keep an eye on latest security vulnerabilities and act on them as needed. HN saves so much time for me to keep an eye on what is blowing up around the tech. world.

\- Of course, use SSL everywhere. Letsencrypt makes it easy. Don't be too lazy. Just install the damn SSL.

\- Be careful of "social engineering". Your system may be very secure but it just takes one badly trained customer service rep or email to hack into your system. If someone requests any client access, check their credentials of who they really are. Don't just respond to an email just because it seems to come from your client.

\- Finally, take a chill pill and don't lose too much sleep. Every system is prone to security issues so as long as you are doing the important things, you should generally be ok unless you are specifically the target which usually is not the case.

<comment><USER6> > We all know that

I disagree, I think a LOT of developers are quite arrogant when it comes to security "how hard can it be?".

Have a look at some of the answers to this reddit question.

[https://www.reddit.com/r/ruby/comments/5wp0rh/how_to_approac...](https://www.reddit.com/r/ruby/comments/5wp0rh/how_to_approach_replacing_a_custom_authentication/)

</comment></comment><comment><USER7> You really need to think about security as a few distinct, but related parts. There's (at least) infrastructure, data and product security to consider.

1\. Infrastructure security is because you don't want intruders on your servers. If you don't control access to the actual servers and your own SaaS accounts, and have systems to detect and alert when something abnormal happens, then all bets are off.

2\. Data security is because my data is important to me, and I want you to keep it confidential. Store it encrypted. Encrypt in transit, even inside your network. Don't send confidential stuff over Slack. The data a customer puts into your SaaS product should be safe and secure from anyone else who wants to see it.

3\. Product security options are required when selling any SaaS offering today. Build and enable 2fa. Build a feature to allow for role based access controls. Don't build any system that would enable you to send me my password in an email. This is a huge list to make.

We recently launched an open source guide for product managers of SaaS applications to use when trying to build for the enterprise. It's at [https://www.enterpriseready.io](https://www.enterpriseready.io). There are a few relevant sections for this conversation: Product Security, Audit Logs, Role Based Access Control. I'd encourage you to read those sections, and send any feedback. Our team has been working on problems in this space for a while now, and put a lot of time into building those guides.

</comment><comment><USER8> I'm working on a SaaS in this very space - helping businesses to secure their customer details and identify data breaches early, so that you can be proactive in your mitigation and cleanup.

I am working to get the idea validated, so if anyone would like to get in touch, I'd love to chat (be it with fellow SaaSs, or startups etc).

My email is in my profile.

</comment><comment><USER9> I wonder how you calculate money loss, if your service is hacked.</comment>


With 1.2M Members, Sincerely Goes Up Against Facebook With Gifting - <AUTHOR> http://techcrunch.com/2012/11/14/sincerely-gifting/

<comment><USER2> How is it going to deal with these:

[http://patft.uspto.gov/netacgi/nph- Parser?Sect1=PTO2&Sec...](http://patft.uspto.gov/netacgi/nph- Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch- bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=facebook.ASNM.&OS=AN/facebook&RS=AN/facebook)

[http://patft.uspto.gov/netacgi/nph- Parser?Sect1=PTO1&Sec...](http://patft.uspto.gov/netacgi/nph- Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=8,190,519.PN.&OS=PN/8,190,519&RS=PN/8,190,519)

<comment><USER3> _shrug_ ignore them and keep doing what they're doing? No need to worry about it until it becomes a problem.

<comment><USER2> And when it becomes a problem, they can make an injunction and shut you down having made you waste a lot of money and time?

<comment><USER4> If you don't build things covered by patents, you would quite literally never build anything - particularly in the software world, which is riddled with useless patents.

martythemaniak is right - build it first, worry about patents later.</comment></comment></comment></comment>


Ask HN: We have free SSL certs now. Isn't it time we got free domain names? - <AUTHOR> Is it possible? What's the actual cost of maintaining a TLD registry? Can it be funded like LetsEncrypt?<p>(Ignoring blockchain-based name registries as they aren't universally supported, and still cost money.) <comment><USER2> The main issue that has to be solved is name squatting.

<comment><USER3> This indeed seems to be the main issue (which LetsEncrypt didn't need to worry about). Zero cost would necessarily mean that early users will hoard all the valuable names, leading us back to square one.

Human-recognizable names are a scarce commodity. Zero price would create a market distortion.

</comment></comment><comment><USER4> Unfortunately ICANN has issued lucrative contracts allowing registries to charge ~$8/year/domain or more and it seems like the cost of providing those registries has expanded to consume all that money (like in the old days of Ma Bell). Companies will never give up that money.</comment>


Getting Web Scale with PHP & Memcached - <AUTHOR> http://www.re-cycledair.com/getting-web-scale-with-memcached

<comment><USER2> The term "web scale" needs to go away; it just doesn't make sense. No one site will ever need to be "web scale" by its definition since it's highly unlikely one site will get all of the web's traffic. The term could only apply to a crawler or something similar that actually consumes the whole web. Your website will either scale or it won't and there are various levels of magnitude, but the term "web scale" is confusing and buzzwordy.

</comment><comment><USER3> Pretty basic article, but yes, Memcache is awesome. With a PHP/Memcache/Nginx stack I was able to make a massive traffic site work on the smallest-possible EC2 server. But there are two things that are even more important when running PHP: a good FastCGI server (such as PHP-FPM) and an opcode cache like APC. Without those two, the PHP CGI execution model would be pure insanity; not only would it restart the entire process for each request, it would also recompile every file. I think it's sad that those measures are not standard in every PHP environment, but then again they're not particularly difficult to configure...

</comment><comment><USER4> To anyone else that might start with Memcache it should be noted that it does not fail gracefully if your servers decide to crap out. We deployed a group of 8 Memcache servers to our production environment and due to a mis- configuration all the webservers were brought to their knees since the get/set would wait for the Memcache server to respond even with the PHP specific settings (timeout etc..) set to appropriate values. For a safe use you should implement a simple home-grown "active memcache server" list so in the event of utter failure only the first couple requests to Memcache will try to request from the server list and as they fail you can knock them out of the pool. It's worth the 10 minutes it takes to implement and will save your ass if things go wrong.

</comment><comment><USER5> Sums it up pretty good. Only thing is, memcached is kinda outdated, it's not safe, can put very easily your environment at risk in case of crash. For anybody starting to wander in the world of caching with PHP, i'd recommend Redis, much better, safer and on an other planet when it comes to features available.

<comment><USER3> You're right that memcached does not have security features (though I believe they added basic authentication). In fact, it couldn't be any simpler in its design, it really has only one feature at all when it comes right down to it. This limits its usage, but its simplicity is also a big strength as long as programmers and sysadmins don't lose sight of its purpose.

I have not used Redis (yet), but from what I understand it really solves a different problem. It's a key-value store. Though Memcached data is also accessed by keys, it is not a store, it's a very fast cache with minimal overhead.

<comment><USER5> Redis solves the same problem, while offering way more features. In terms of speed, Redis is in the same area.

Memcached is also a key-value store (quote from the official site "Memcached is an in-memory key-value store for small chunks of arbitrary data"). I've been slowly using Redis more and more over the past 6 months, and as an heavy memcached user, i can tell you that i don't really see a need for both, might as well take advantage of the useful features Redis as to offer on top of the "basic" Memcached-like stuff.

<comment><USER3> Redis is persistent, replicated storage, isn't it? No matter what buzzwords they use on their site, Memcached is a volatile cache, it should never be used to store otherwise irretrievable information. I know, people use it for stuff like session storage, but that's really not a good use case for it.

I don't want to attack Redis, so there is no need to defend it. Maybe memcached-like behavior is one of its many features, but I personally like Memcached exactly because of its simplicity.

</comment></comment></comment></comment><comment><USER6> Caching 101.</comment>


High frequency gravitational wave generator - <AUTHOR> https://patents.google.com/patent/US10322827B2/en <comment><USER2> So they're gonna use this to deflect asteroids and prevent doomsday scenarios.

<comment><USER3> Or more likely spacecraft engines. Going to Andromedar needs such a system, as you cannot carry enough fuel for conventional engines with you. I think Martin Tajmar has a similar patent on this already.</comment></comment>


Why Humility Also Means Ignoring Advice - <AUTHOR> https://medium.com/life-learning/why-humility-also-means-ignoring-advice-4c6e11b2bc67 <comment><USER2> This seems to be trying to redefine humility.

To me, what they are describing sounds more like authenticity vs inauthenticity, or honesty vs dishonesty, than it sounds like humility vs pride.</comment>


Betrayal - <AUTHOR> http://haacked.com/archive/2014/01/02/betrayal/

<comment><USER2> What does this guy know about Open Source? It's not like he dedicated years of his career encouraging Microsoft to warm up to Open Source or works at GitHub to make it easier for developers using Windows to use Open Source.

Or wait, he has done all that? Next you'll tell me he's super handsome and has a beautiful family. Now you're just pulling my leg.

<comment><USER3> He's also IronMan.

[https://s3.amazonaws.com/github- images/blog/2011/PhilHaack.J...](https://s3.amazonaws.com/github- images/blog/2011/PhilHaack.JPG)

<comment><USER2> We should listen to this guy. Not many guys can pull off a striped shirt that well.

</comment></comment></comment><comment><USER4> It feels like the people Phil's reacting to ("an industry with rather paranoid clients that contractually bar us from using Open Source software") are bad at convincing their clients.

The solution isn't "learn to use open source because it's generally a better model for collaborating on software" as Phil suggests. It's "learn to educate your clients better, so that they don't contractually obligate you to do silly things".</comment>


Goto in C - <AUTHOR> http://neverworkintheory.org/2016/06/09/goto-in-c.html <comment><USER2> The actual paper ([http://www.se.rit.edu/~mei//publications/publications/FSE201...](http://www.se.rit.edu/~mei//publications/publications/FSE2015-Nagappan.pdf)) is far more interesting that the linked post. The conclusions that goto is mainly used for cleanup and error handling isn't surprising. However, the study doesn't include the Linux Kernel or other kernels.</comment>