Why apps are not the future - <AUTHOR> http://scripting.com/stories/2011/12/13/whyAppsAreNotTheFuture.html <comment><USER2> Linking is one of the things that I think Android got right over iOS. Google -- web company that they are -- smartly realized that their mobile OS platform needed to borrow metaphors from the web and attempted to do this with their Intent/Activity architecture.

The challenge here is the execution -- it's Java-heavy and unwieldy compared to <a href=...>, but the basic structure is there and allows for interesting interleaving of Activities from one app into another. I haven't yet seen a lot of discussion or adoption of Open Intents, but I think it's an interesting approach. It does, again, seem to suffer from an inheritance of Java's heaviness, and that may be a fatal flaw.

<http://www.openintents.org/en/intentstable>

Whether this approach succeeds in sustaining rich-client apps as web apps mature remains to be seen, but I do think it points to the fact that OP's criticism was a concern in the minds of Android's developers at the earliest stages.

<comment><USER3> You can link apps in iOS too. You can do a simple test: open safari and type fb://feed and it will open the facebook app and go to your wall.

More: [http://wiki.akosma.com/IPhone_URL_Schemes#Registering_your_o...](http://wiki.akosma.com/IPhone_URL_Schemes#Registering_your_own_URL_schemes)

<comment><USER4> How does iOS handle multiple apps registering for the same type of URL? In Android, I get a popup asking which app I want to use for this action, and an option to make that the default for future actions. Is there something similar on iOS?

<comment><USER5> You get a popup asking which app to use. I don't think there is a "save as default" because that would necessitate a way to manage those defaults, which would expose the underlying mechanism to users, something Apple is generally averse to doing.

The reality is that it doesn't get used a whole lot. Browsers, Dropbox, and other apps of that nature tend to provide the data while miscellaneous apps consume it.

</comment></comment></comment></comment><comment><USER6> I believe native and browser-based apps can and will coexist.

As a web developer, I've had my share of frustrations with the browser and I certainly would welcome a more flexible and feature rich alternative for some use cases.

To give an example, I can see native development overturn browser dominance in the manufacturing of Content Management Systems. For years these apps have been tied to browser technology and their usability and features have been limited because of it. Sure it makes them easy to deploy (all you need is a browser), but in exchange you get crappy wysiwygs, lack of remote access (ftp, ssh), image editing that sucks and a string of other annoyances that we've simply learn to accept out of convention.

But when you think of it, there's no reason it should be like this. Organizations typically only have a handful of people that require access to the admin panel. You could simply have them install a native client that communicates with the server via http, exactly like the browser does, but offers a much more elaborate API. The added bonus would be the possibility to easily delegate various other tasks to other tools (Unix style).

Other normal web users (consumers) can continue to access the frontend (as opposed to the admin panel) via browsers.

This is a future I can definitely embrace.

<comment><USER7> I'm not sure I agree. Since I discovered Google Apps, I forgot about Microsoft Office.

Google Docs is always there. It may be a crappy experience on my Android, but I have access to content I wouldn't otherwise. Collaborative editing and sharing is really easy too - I don't have to ask other people to buy iPhones / iPads / Androids to get them up to task. They only have to have an email on which I send an invite. And sure you can make a better native app and I would appreciate one on my Android, however I remember how this one time I forgot my phone and borrowed the iPhone of a friend to access a really important document.

On the whole, web apps are more accessible. Native apps are a nice bonus to this experience, however if the core is not web-based, then it loses a lot of value.

<comment><USER8> """On the whole, web apps are more accessible. Native apps are a nice bonus to this experience, however if the core is not web-based, then it loses a lot of value."""

Well, that can be easily solved with native apps that also have a web counterpart, for desperate times (i.e in the middle of Tahiti without your laptop/mobile phone/tablet).

</comment></comment></comment><comment><USER9> We keep having the same debates over and over. We've seen this before on the desktop. It started with apps that had to be written for both Windows and Mac. Then the web came along and, as bandwidth increased, many apps were able to be run as web apps, simplifying code maintenance and giving developers the ability to easily target multiple platforms. Apps that benefit from linking work better as web apps. Some types of apps, however, run better as native apps: things like games and Photoshop. So we ended up with both.

Mobile will follow the same track: we'll end up with both.

<comment><USER10> The reason why this conversation is coming up again is that so many applications that are web applications on the desktop are more commonly accessed as native apps on mobile. For example, on iOS I use a native client for IMDB, my bank, Mint, Wikipedia, and so on. But on the desktop I use web sites for these services. There has been a shift _back_ to native on mobile.

I agree that we'll end up with both but perhaps more importantly is that the difference between web and mobile will blur together even more.

<comment><USER11> I think the real reason that you see apps on mobile devices is that an app puts an easy to use branded icon on the "desktop" instead of requiring the user to open a browser and navigate to the site. I don't think it has anything to do with lack of access to capabilities (e.g. Mint doesn't need access to my camera).

Try this thought experiment: What do you think would be the reaction from users and developers if Apple simply renamed Safari's "Add link to home screen" option to "Install App"?

<comment><USER10> I never said anything about "lack of access to capabilities". Native applications, in the vast majority of cases, are just better in every way than the similar web versions. They're faster, cleaner, and more capable. If both are being offered, it makes no sense to choose the web version.

My company makes an iOS-compatible web application with no plans for a native client right now. We use some JavaScript[1] to remind users to add us to their homescreen. But if we had the resources, we would build a native client -- it's a no brainer.

[1] <http://cubiq.org/add-to-home-screen>

</comment></comment></comment></comment><comment><USER12> Webapps need to better handle offline usage and poor network conditions. Until then, apps still have a huge leg up on mobile devices.

Mobile devices are battery constrained. Radios to provide data feeds are a big factor in battery drain. Interpreted languages increase battery drain. And network coverage is far from universal, to say nothing of download caps and cell network performance concerns.

Apps are preferred today because they're more responsive, they drain less power and they're generally usable offline and in dodgy network conditions. The web has many advantages over native applications, but until it gets better for mobile users, users are not going to get past the more-immediate shortcomings to care much about those advantages.

And given that we seem to have reached a point where potential battery life past 1 day of solid use is traded off for greater performance during operation, I don't see the battery/network situation changing much any time soon.

<comment><USER13> By the same argument, though, apps will be obsoleted as soon as the next battery technology arrives, because, let's face it, installing apps, updating and uninstalling is a ghost long dead. As soon as Apis to access camera, microphone etc come to the browser, who would choose to program native?

<comment> bulte-rs > installing apps, updating and uninstalling is a ghost long dead.

So, when not installing native apps (which takes time) we add - in the case of e.g. the iphone - webapps (links) to our home screens. Which is faster than installing a native app. After that we 'endure' a longer loading time every time we start the app. And we still have to remove the icon from our home screen when we're done with it.

Mind you, I see the advantages of web apps; but this does not seem like any different from the native app use case; it seems a bit worse to me actually.

> who would choose to program native Performance junkies? graphically > intensive app-developers (games?). Sure, we may have an 'opengl'-component > to use in our webapps; but why the extra overhead?

<comment><USER13> Web app icons don't make sense as you 'd soon end up with thousands of them. I imagine future phones will just have a voice-recognition-enabled search box instead of icon grids.

<comment> bulte-rs The same could be said about native apps. There are more than enough apps in the various app stores to fill numerous 'springboard screens'. On the other side we only use a small set of apps. Why would habits change when switching from native to web-based when the experience is the same?

</comment></comment></comment></comment></comment><comment><USER14> I agree with the sentiment of the op, however, I dont think you can ignore the fact that so many people are willing to spend a dollar or two on an app whereas paying for access to a web site seems relatively rare (outside of the business world).

<comment><USER15> Show me a (useful) website that costs less than $5 for lifetime access.

Many SAAS companies charge the same as an app, but _per month_ , so you can't really compare it with a one-off payment.

<comment><USER16> <http://www.google.com/>

<comment><USER15> I don't understand whether you're trolling or not. Google doesn't make you pay for access, last I checked.

<comment><USER16> >>> Show me a (useful) website that costs less than $5 for lifetime access.

The business model is often completely different for the web. We pay with our eyeballs (ads) and our thoughts (click data).

<comment><USER17> Nice. So that pretty much guarantees that only those SAAS apps that are operated by the largest corporations, and that harvest your personal data most efficiently, are the ones that dominate. Everything else is only that much more likely to disappear in an instant, taking with it not only all your documents, but the app's functionality itself as well. I really don't know what people like you are smoking.

<comment><USER16> I only smoke weed. But yes, outside of fairly niche markets, the largest corporations are dominating (Amazon AWS, Google Docs). It IS a lot more likely that any of these alternatives ([http://www.makeuseof.com/tag/5-great- alternatives-to-google-...](http://www.makeuseof.com/tag/5-great-alternatives- to-google-docs-you-should-consider/)) will disappear with all your data than that Google Docs will. I'm not saying it's some awesome thing that big businesses can out price the little guys and I'm not saying that the profitable SAAS does not exist (Harvest, Github (most of Github's users don't pay a dime)). The simple reality is that most people get a fair amount of utility from free web services.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> _"Visualize each of the apps they want you to use on your iPad or iPhone as a silo. A tall vertical building. It might feel very large on the inside, but nothing goes in or out that isn't well-controlled by the people who created the app. That sucks!

The great thing about the web is linking."_

I'm not convinced. I see the "app" response to "linking" as being something like Windows 8 contracts. In fact, I wouldn't be surprised if iOS and Android have something similar to contracts in the next 2-3 years. At least I would hope so!

I think that there are applications that make more sense to implement as a traditional app, and that there are applications that make more sense to implement as a web app. I don't see this changing anytime soon. I really don't.

<comment><USER19> Well, Android has "Intents", which allow similar functionality, although not as much as "Contracts" if I understand correctly.

<comment><USER18> I was actually not familiar with Intents. Good to know.

</comment></comment></comment><comment><USER20> I don't think anyone outside of the app-development ecosphere seriously thinks that the Web is dead. It's a pretty absurd thing to say.

<comment><USER21> As a web developer, I think it is dying, but not in the way you immediately think.

Modern websites are starting to resemble full-fledged applications. Built using entire MVC frameworks atop the Javascript runtime that abstract the underlying primitives, just like their native brethren. Today, from a programmer's standpoint, there is little difference between building a native and web application.

Every new browser iteration just brings tighter integration into the underlying system. There are no real web-specific technologies being introduced. We are reaching the point where the web serves little purpose other than a clumsy virtual machine. The natural progression will be to go full on virtual machine, like Java attempted to do many years ago, where HTML/CSS/etc is just another application on that virtual machine.

The idea of pointing a browser to an address to open an application will stick around, but I think the web parts, a program that renders interlinking hypertext documents, is dying – though certainly not dead yet.

<comment><USER7> In the meantime Wikipedia is still the most useful product of the Internet and the biggest database of human knowledge. It's only surpassed in traffic by Google, Facebook, Youtube and Yahoo.

        the web serves little purpose other than a
        clumsy virtual machine

That clumsy virtual machine can bring you Facebook.com on every mobile phone, regardless of the platform. And if good native apps are now available for Facebook, well, we are talking about Facebook.

<comment><USER8> """In the meantime Wikipedia is still the most useful product of the Internet"""

You missed the point.

There's nothing Wikipedia does that cannot be done in an native-gui mobile App.

It's just a list of articles, a way to search for them, and a system to edit them. Nothing web particular about Wikipedia, one can imagine a Wikipedia app for mobile and desktop OSs that achieves the exact same thing.

<comment><USER20> But surely the success and therefore usefulness of Wikipedia is down to the fact that it's available to everyone with a web browser? Apps are only ever going to have a tiny proportion of the target market, compared to the number of general web users out there.

That's what this is about. Of course you can do the same functionality that's made Wikipedia work in an app, but I don't think you'd ever get the numbers needed to make it useful.

<comment><USER8> """But surely the success and therefore usefulness of Wikipedia is down to the fact that it's available to everyone with a web browser? """

It's success when it was created, and maybe now, yes.

But how about a future where everything has a mobile phone and/or tablet, but fewer have or care to use a web browser?

<comment><USER7> Normal people never cared about web browsers, but that didn't stop web browsers from spreading like a virus. Most of them don't even understand the concept. If you ask them what a browser is, they'll probably answer Google.

As an example, I love my e-Ink Kindle. The one big annoyance I have is that the browser on it is so awful that it is unusable. And it bothers me because book authors are often placing links to external references in the books I read.

And I just want to read those references. Maybe add a comment or two if it's a blog. Since I'm there anyway, maybe I want to recommend the book on Facebook or Twitter with, you guessed it, a link. Maybe I want to search on the web for other discussions on the topic. And so on and so forth.

It's not about love for the web browser per se. The browser is an awful virtual machine. Also the HTTP protocol is one of the featureless protocols in existence. The development model is scary sometimes as you've got to learn dozens of technologies, each specialized for a certain task, each broken in its own special way.

But developers bitching about this are missing the point. It turns out that the openness of the web is disruptive and simple form elements communicating over a simple protocol is all you ever need for 80% of the use-cases.

Quite the contrary, I'm seeing the web stronger than ever before. The one big problem I'm seeing however are walled gardens. Some day from now we'll look back and actually see what a big mistake this was. But the web as we know it will still be there. Because nothing can really replace it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> You gotta love IT.

On Windows there was perfect integration between apps after Microsoft added linking and embedding using COM/OLE. 2D/3D hardware acceleration was standard. Linux as a competing OS implemented most of this also. Then came the web, and after years of standardization we now have hardware accelerated 2D & 3D, near- native performance (albeit using a completely new toolchain) and most of the standard desktop things. We have gained platform independence and ubiquity. Now we have to reinvent everything on mobile devices.... Granted, most of it is already there. But I sure would love to see most new mobile apps implemented in HTML5, to make them work cross device as much as possible.

<comment><USER8> I wouldn't call COM/OLE "perfect integration between apps" at all.

And no, "2D/3D hardware acceleration" was not standard for the majority of Windows applications out there, including the Windows desktop.

<comment><USER2> "I wouldn't call COM/OLE "perfect integration between apps" at all."

Oh come on, it was so simple! All you had to do was set up a ProgID and/or a GUID in the registry (no! not HKEY_LOCAL_MACHINE, silly!, HKEY_USER! Oh wait, you're right, it is HKLM...) and then implement IUnknown in your app and the register the interface when you installed your app...hopefully with Windows Installer, which makes all of this a simple 15-step process. There's only like, 25 different registry keys to keep track of and 12 layers of interfaces to implement.

It was perfect I tell you!

</comment></comment></comment><comment><USER23> I think we've lost focus here. Web pages as apps are silly, but there are just things you can't do from a web page on a mobile phone, like interface with the camera, GPS, compass, local caching, etc... That's where apps come in (or should).

<comment><USER11> PhoneGap exposes those features to JavaScript through Device APIs.

<comment><USER24> Lol, was about to mention PhoneGap.

</comment></comment></comment><comment><USER25> I can think of more reasons:

\- app discoverability sucks ass

\- apps require updates

\- app development is unnecessarily tedious and must be done x number of times for x platforms

\- iOS apps need to be approved by Apple, and you have to play the game by their rules if you want to charge money for them

\- apps lack basic features of browsers - no universal find, no back/forward buttons, no bookmarking of pages or states, no organizing apps into tabs, etc.

Let's be honest: not counting games, the vast majority of the native apps out there would work just fine (or better) as websites. Add API's like access to the camera and there's even less reasons to develop a native app.

Apps will be relegated to games and highly sophisticated interfaces, which if I had to guess probably represents around 10% of all the apps out there (heck, most of the games out there could probably be done in the browser).

</comment><comment><USER26> Linking is really the only feature I care about in the web. And it's not a negligible one. I'm tired of all the Flash animations, the AJAX updates or other fade-ins and shiny effects. It looks pretty, but I'm not connecting to a website to watch a fashion show, I'm really here for the content.

I wish we could go back to a more "HTML-only" oriented web. You still find some of those (usually with old Unix hackers or computer scientist) and they're amazingly enjoyable to read. Also, parsing them and running grep/sed/awk/... is a breeze. Am I crazy to ask for data I can manipulate easily?

</comment><comment><USER27> You _can_ link with apps. Intents do this.

[http://developer.android.com/reference/android/content/Inten...](http://developer.android.com/reference/android/content/Intent.html)

<comment> k-mcgrady To an extent you can do this on iOS as well with URL schemes.

</comment></comment><comment><USER28> I think one potential answer to this is the ability for mobile/tablet apps to embed a browser inside the app. So you see this already with the twitter app on the ipad, when you click a link, it opens a browser in-app. The app makers don't reaaaally want you to leave, so the in-app browser is a nice compromise for them. And as a user, I like it. I don't necessarily need/want to leave the twitter app on my ipad. I just want to read the linked content real quick and jump back to the app. Works for me :)

<comment><USER29> Unfortunately, the browser experience can vary drastically depending on the app linking out. Plenty just dont at all. You see a link, but clicking doesn't do much but let you copy the text, if you're lucky to even have that. It's frustrating and makes me tend to avoid links in most all apps.

Take Flipboard, and otherwise beautiful app that is the gold standard for future blockbuster apps; when you decide to open a link to a full article you will get stuck inside an awkward hardy-useful piece of Safari. Even if you click out, you efffectively lose your place in the flow of what you were browsing. This is an example of bad integration from the browser. Don't even get me started on the apps that come with built-in browsers that feel like a toynrather than a tool.

I want to read the linked content _not necessarily_ real quick and return back, and trust that the experience will be as good as a native app. In a perfect world all Apps would be web apps.

</comment></comment><comment><USER30> Why does it have to be binary? Why does one school of thought have to lose in order for another to win?

</comment><comment><USER31> Regardless whether the author is right or wrong, "I don't care" is not a valid way to dismiss a counterargument. It's an effective way to resolve cognitive dissonance however.

</comment><comment><USER32> Another thing I recently realized: if the trend is to store everything in the cloud. How long until we also store apps in the cloud? Oops, they are now web sites...

<comment><USER33> Not just _any_ websites, but websites locked down by Apple/Microsoft/whomever _for your own good_!

</comment></comment><comment><USER34> Deep linking is perfectly possible in apps. The !# hasbang is ugly, yes, but the HTML5 History API corrects this with the ability to pushState, replaceState and popState without necessarily having to deal with hashes.

Moreover, this style of linking matters most with publicly available data. For private data, such as the stuff I'm working on storing in the browser with IndexedDB, having a public link isn't necessary for data that's not publicly available. I of course want to support browser history/links in full (see <http://warpspire.com/experiments/history-api/> for an example of what's possible) but my point is that when apps are personalized there is not always a need for a link that can be shared across the web.

If I wanted to prognosticate about our web-based future I'd look beyond vanilla hyperlinking and at Web Intents instead.

</comment><comment><USER35> Apps are shaping into Native, Hybrid, and HTML5. Native will always own a) 3D & graphics, and b) frequent users. HTML5 is in the immediate future shaping to be a 'try before you download' the app. It will be dominant in one time use (web) apps. I am working on an HTML5 marketplace- PM me if you're curious

</comment><comment><USER36> A friend brought up a good point the other day that the popularity of the iOS app store has actually pushed back on advances in web technologies on mobile devices. Because the sanctioned way to sell applications must go through Apple, less attention overall has been spent building mobile webapps. Also, since the hardware is also out of developer's control, there hasn't been a push to make native hardware available to the javascript.

Even with that, I do think that we're on the cusp of a big webapp revolution (again). With all these emerging JS frameworks (backbone, ember, derby, knockout, etc), and the modern and capable webkit powering so many mobile devices, developers will take note.

</comment><comment><USER37> You know the people who make phone software are actually aware of this?

In Android, the concept of Activity and Intent serves to essentially promote this. Its not a solved problem by far, but work HAS been done in that direction. Rest assured, this work is only going to speed up from here.

After all, smartphones and tablets are marketed as consumption devices. The manufacturers would be hugely remiss if they didn't learn anything from the internet. And as we know, Steve Jobs and his industry descendants are anything but remiss.

This is not to say the OP are wrong. Web doesn't compete with apps, it supports them. The two are complementary paradigms, not competing.

</comment><comment><USER38> It is easy for me to imagine a world that moves from the messy chaos of the web to the clean, self-contained, predictability of the app, and linking would be a mere ancillary concern.

Apps are the path of least resistance for the consumer.

</comment><comment><USER39> Has it ever occurred to you that the next generation technology might harness the advantages of both apps and the web?

That's the way innovation occurs. Incremental improvements. Referring back to past implementations. Standing on the shoulders of giants. Learning from both the good and the bad of technology.

When people bring up the debate of Apps vs. Web, it's equivalent to saying " _Facebook vs. Google+ - which one will people use in the future? You either get the Facebook like button or Google circles. One or the other, but not both_."

<comment><USER40> How exactly will it happen?

</comment></comment><comment><USER41> Yep, completely agree with the article. For me an important difference between the 'web' and 'apps' is that generally speaking nobody builds mobile apps out of generosity or egalitarianism, ie to give something to the world for free - mobile app developers are in it for the money.

However, the openness and non-proprietary nature of the web seems to encourage people to be generous and share content and services.

How many open source mobile apps are there compared to really great open source web/pc software?

</comment><comment><USER42> Apps allow content provides to hide their data and only share it in a highly controlled environment. It's very unweb like, but appears that controlling a scare resource is profitable.

</comment><comment><USER43> >It pleases the money folk to think [...] That users are happy to live in a highly regulated, Disneyfied app space, without all that messy freedom.

Sadly I think those folks are right. Shiny things do appeal to average people above freedom, flexibility etc. Given enough people with both money and an interest in shiny things, apps will rule supreme.

<comment><USER8> It's not like the flexibility to export you data in some format or the freedom to modify the code means anything to people --or like it _should_ mean.

How about the freedom from baby-sitting your OS install and the flexibility to just use a nice, polished app and go on with your REAL work?

</comment></comment><comment><USER44> The web will prevail. It's just question of time.

Just be smart and make profit with the app fever while you can.

</comment><comment><USER45> Linking is nice but the real killer feature is that installing, updating, and opening a website happen at the same time. Apple, Google, and Microsoft can build their own linking mechanism, but I have to preinstall the app before the link will work.

<comment><USER46> Fixing that is not too hard. If you look at Mac OS X Lion, for instance, part of that already is in place (in a different domain). If you download a .xyz file and double-click it, the Finder will suggest looking for applications that can open .xyz files.

I think a logical extension would be that the system would automatically download free viewer apps instead. Add a seamless way to upgrade to the editor app, and you are all set (tangentially related: I think a thing like OpenDoc using that infrastructure could succeed in today's market)

<comment><USER45> Could they download and install these viewer apps in a fraction of a second or two, because thats what a browser does. The web works on the basis of progressive enhancement so all the browser needs to fetch is one Html file which it can display to the user while it downloads all other resources. I don't see a native code matching that.

<comment><USER46> _"all the browser needs to fetch is one Html file which it can display to the user while it downloads all other resources."_

If only. There are pages where that is possible, but typically, at the very least, browsers need to download some css, too (for example, google.com, on my system, does 9 http requests of which one fails). Even with inline css, a browser can discover, halfway through a file, that some css moves a div up top, floats it, etc.

Add to that 'not everybody' specifies image dimensions in the HTML and that Javascript that runs on page load may do DOM updates, and you get a much more complex model. Deciding when to start rendering a page is somewhat of a black art. If you wait until you are sure you have all information you need, the browser will appear slow; if you do not, you will have to restart page layout sometimes.

 _"in a fraction of a second or two"_

Pages that load at that speed are rare. Again taking google.com as example, it loads almost 200kB here (most of it from cache, but that would not be much different in what I envision). When running from cache, rendering that simple page takes about half a second, I guess (FireBug reports 700ms and up, but it will have some overhead)

</comment></comment></comment></comment><comment><USER47> He means iOS apps, not desktop apps, right? Desktop apps aren't "silos". The PC/Mac is a personal systems-integration device with mechanisms like pasteboards to transfer data between apps. Unfortunately iOS (so far) has very little of this.

</comment><comment><USER48> Very basic but there is a way in iOS

[http://iphonedevelopertips.com/cocoa/launching-your-own- appl...](http://iphonedevelopertips.com/cocoa/launching-your-own-application- via-a-custom-url-scheme.html)

</comment><comment><USER49> I think apps are here to stay, but just like in the Chrome browser they might be simply links to a web-app. So the title should read "Why native apps are not the future".

</comment><comment><USER50> that's all well and good. the key is that you can sell an app easily given a unified interface. that beats everything that is being done on the web, hands down.

We have to understand that apps make money and that this is why people will have people write more apps, which will fuel the economy and (us) entrepreneurs. That someone will switch off the web at some point is somewhat unlikely and when the time comes, probably secondary.

</comment><comment><USER51> The URI (or now more correctly, IRI) is a Web concept that is just as applicable in native apps as it is in HTML/Javascript apps. Use it.

</comment><comment><USER52> > Why apps are not the future

They are not the future indeed. They are the present.</comment>


Photoshop Turns 20 Today - <AUTHOR> http://tv.adobe.com/go/photoshop-20th-anniversary

<comment><USER2> I didn't know about the early history of Pixar and the Pixar Image Computer (<http://en.wikipedia.org/wiki/Pixar#Early_history>).

</comment><comment><USER3> Obligatory comic link: <http://m.assetbar.com/achewood/uuacCdS9V></comment>


Do I Own a Shitcoin? - <AUTHOR> http://www.doiownashitcoin.com/ <comment><USER2> This looks like really low quality content. It perpetuates the lowest common denominator, fanboy, unintellectual, meme-based discourse that has plagued cryptocurrency since the beginning. You're not doing anyone any favors with this content.

<comment><USER3> What I'd like to see would be this site except each quip being followed by a link to back what was being said. But yeah, it's just a joke/meme site obviously so we'll just have to take it for what it is.

</comment></comment><comment><USER4> Answers are randomly picked, however this is an accurate point of view : no one know, everyone says something different, we all prey for magic internet money with a shitty justification ...

</comment><comment><USER3> So I checked what it said about BCH, and then I checked the tips button and for a moment I was like but then why do they take tips in BCH. Then I saw what they said about receiving BCH tips. All is well XD

Also checked what was said about XRP and was not disappointed.

</comment><comment><USER5> This is stupid, how can BCH be a shitcoin? The explanations for why a coin is a "shitcoin" are short and memey. People without technical backgrounds should just stop giving their opinions on the "true" utility of a coin

<comment><USER6> Roger Ver, Jihan Wu, deceptive marketing, laughable dev team...

<comment><USER5> no technical analysis

I could just as easily say "block stream, censorship, lightning was a joke, pro-centralization". The entire point was that short quips like that are meaningless and insufficient

</comment></comment></comment><comment><USER7> This is what it says for DOGE!!

"Such shit, very coin, but HODL for that yearly pump"

</comment><comment><USER8> Canned crap: view- source:[http://www.doiownashitcoin.com/static/js/dioas.js](http://www.doiownashitcoin.com/static/js/dioas.js)

</comment><comment><USER9> MAID is "not bad"? It's the shittiest shitcoin, a coin that has nothing but marketing and a number of unworking prototypes developed by cheap outsources. How is that "not bad"?

</comment><comment><USER10> I was surprised to se it list C20 as a shit-coin. It's a automated index-fund over other currencies, most of which it does not list as shit-coins..What are these assertions even based on?

</comment><comment><USER11> programmatic variant: [https://github.com/hikari-no- yume/BitcoinOrBitcon](https://github.com/hikari-no-yume/BitcoinOrBitcon)

</comment><comment><USER12> Right idea, poor execution</comment>


Flipboard showing East European language articles for HN feed - <AUTHOR>

I verified it on a colleagues phone (I have an Android phone, he has an iPhone) and both of us are seeing entries from ~2 days ago and all entries are in a East EU. Every Single Article.
Is anyone else seeing this? Is this something at Flipboard's end?
ETA: A quick search of Twitter shows that I'm not alone and other folks are seeing this.
A screenshot of what I'm seeing - https://www.dropbox.com/s/xev66oishst6ox2/flipboard-cyrillic.png?dl=0 <comment><USER2> Same here... iPhone 6+ maybe they are on top of it.</comment>


Apple Tells Gliph to Remove App's Bitcoin Transfer Function - <AUTHOR> http://www.coindesk.com/apple-gliph-remove-app-bitcoin-transfer/ <comment><USER2> Fortunately the developer of CoinJoin built an HTML5 wallet which is unbannable by Apple:

[https://twitter.com/kyledrake/status/406604212009566208](https://twitter.com/kyledrake/status/406604212009566208)

<comment><USER3> I've been waiting for the day when Apple axes the "Add To Home Screen" functionality entirely. It's a holdover from pre-App Store days, and has been sadly neglected; iOS7 shipped with several show-stopper bugs [1], only some of which have been fixed.

I have a feeling that they only keep HTML5 apps around as a pre-emptive defense against anti-trust.

[1] [http://www.mobilexweb.com/blog/safari-ios7-html5-problems- ap...](http://www.mobilexweb.com/blog/safari-ios7-html5-problems-apis-review)

<comment><USER4> Agreed. It was a great feature when the iPhone launched but it's barely been touched since. Yet amazingly, it's _still_ the best. Android Chrome only just got Add To Homescreen functionality and it doesn't yet do anything special.

It's even more disappointing that Apple has implemented web push notifications... on desktop only. It's a natural fit for their webapp functionality but I don't hear anything about it being implemented. That plus the ability to register a URL scheme would really be all I'd want from Apple.

<comment><USER5> It can really do a whole lot special with Add to Homescreen as Chrome is running Mobile Safari underneath (the hobbled version for 3rd party browsers) and can't really interact with the OS as much as it can on Android.

<comment><USER4> But they could do a lot with it on Android. And haven't.

</comment></comment></comment></comment></comment><comment><USER6> Before grabbing your pitchforks (again), please take the time to read this article from Gliph that _clearly states_ Apple's policy on why they prohibit Bitcoin: [https://blog.gli.ph/2013/12/09/the-state-of-bitcoin- mobile-a...](https://blog.gli.ph/2013/12/09/the-state-of-bitcoin-mobile- applications-in-the-app-store-and-google-play/)

I really can't blame Apple for wanting to prevent potentially illegal content. When you allow that, you open yourself up to FBI raids, wiretapping, and other unplanned nuisances.

Are there really full Bitcoin wallets on Android? I'm glad that Apple's strict guidelines at least partly force developers to employ smarter decisions regarding disk space, network usage, and battery life (traditional Bitcoin wallets download the entire block chain and constantly poll the network for updates).

<comment><USER7> From Apple: _"We found that your app contains content related to bitcoins – or facilitates, enables, or encourages an activity – that is not legal in all the locations in which the app is available, which is not in compliance with the App Store Review Guidelines._

But this is ridiculous. I can use my Citibank app, the PayPal app, or whatever else, to pay for things that might not be legal either. Square could facilitate me receiving money for illegal things. It's hard to see why these are all allowed, but Bitcoin isn't.

<comment><USER6> The examples you gave don't use Bitcoin; they all use USD. The _currency itself_ is illegal; we're not even talking about what you're doing with the currency. Bitcoin's legality is disputed in China, Thailand, and the state of California. Since Apple operates out of California, it makes sense that they would hesitate to allow such functionality on their apps.

Edit for clarity: I interpret "facilitates, enables, or encourages an activity – that is not legal in all the locations in which the app is available" to mean that _the act of making a Bitcoin transaction_ is illegal in certain jurisdictions.

<comment><USER8> Illegal and "disputed legality" are two entirely different beasts. If the legality is disputed that is for a court to decide, not Apple.

In regard to China specifically they explicitly said last week that it is still legal for private Chinese citizens to use Bitcoin.

<comment><USER9> Apple isn't deciding the legality, they're refusing to allow something of "disputed legality" into the store they run.

Would you be mad at Walmart for not selling a new supplement that was of "disputed legality"?

<comment><USER10> Reddit has content that is clearly, unambiguously, illegal in the UK.

There are apps to access Reddit in the app store.

<comment><USER11> What like cyberbullying? Genuinely curious.

<comment><USER10> Reddit has a pro-suicide sub reddit. It is illegal for people in England to aid someone who is attempting suicide.

[http://www.legislation.gov.uk/ukpga/Eliz2/9-10/60](http://www.legislation.gov.uk/ukpga/Eliz2/9-10/60)

> Criminal liability for complicity in another's suicide.

> (1)A person who aids, abets, counsels or procures the suicide of another, or > an attempt by another to commit suicide, shall be liable on conviction on > indictment to imprisonment for a term not exceeding fourteen years.

This law is mostly used to prevent more active assistance in suicide, but it is also used to prevent people giving advice about how to complete suicide.

So, that's one current sub reddit.

In the past there were jailbait subreddits. I never visited so I have no idea about the content, but English law is stricter than US law around images of people under the age of 18.

<comment><USER11> I only knew there was the /r/jailbait that got removed. A pro-suicide forum is an unsavory thing. Thanks for clarifying.

<comment><USER12> Pro-suicide is tame compared to many of the subreddits out there. If you're curious, do NOT click the links in this collection but rather read the reactions of people who did. (I am serious).

[http://www.reddit.com/r/AskReddit/comments/1qa5ff/what_is_th...](http://www.reddit.com/r/AskReddit/comments/1qa5ff/what_is_the_most_disturbing_subreddit_you_have/)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> Can't wait for Apple to start demanding 30% of all Bitcoin transactions performed on their platform.

</comment><comment><USER13> Bah. This is getting a bit out of hand. It is one thing to maintain quality of your app marketplace, but demanding that people remove features because you are ideologically against them is crazy.

<comment><USER14> I don't believe this is the result of an ideological belief. This is standard Apple app store policy that if you allow any sort of in-app purchases, they have to go through Apple.

<comment><USER7> But my Citibank app allows me to pay bills, transfer money between accounts, and deposit checks. LevelUp allows me to pay for things using credit cards linked to the app.

So it's pretty clear that Apple _does_ allow financial transactions to happen in apps, without taking a cut or anything. What's unclear is why they would allow this for Citibank, LevelUp, etc., but not for bitcoin.

<comment><USER15> The issue is the LEGALITY of the currency.

<comment><USER16> Bitcoin was not illegal last time I checked.

<comment><USER17> The legality of the currency isn't confirmed either.

<comment><USER18> Since when do you have to confirm that something is legal? Isn't the predominant law system on this planet: It's allowed unless explicitly forbidden?

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> This is why I think it's insane when I see Bitcoin-based services built apps for iPhone _first_. How naive are they? It's obvious as night and day that Apple would try to ban Bitcoin apps if they try to get into payments themselves.

We should try and stop them, of course, but why risk it by making iOS your _first_ platform, and even your only platform for a while, if you you're building an app that has a very high chance of getting banned by Apple for arbitrary self-interested reasons.

<comment><USER20> Well to be fair, we released the same Bitcoin functionality for Android and Mobile Web at the same time. This was in May earlier this year (at Bitcoin 2013 in San Jose).

We survived 8 iOS releases with Bitcoin functionality in the app store without hiding that functionality to Apple.

(Gliph iOS Dev)

</comment></comment><comment><USER21> At the same time, Apple openly allowed Blockchain wallet in Mac App Store. [https://itunes.apple.com/gb/app/blockchain/id688882038](https://itunes.apple.com/gb/app/blockchain/id688882038)

<comment><USER22> The Mac desktop is a much less controlled environment. It doesn't help Apple to block a desktop app from their app store because if they do, the developer could release it outside of the dev store. Less apps in the app store means less apps Apple can say it has in the app store.

On the other hand, realistically, the app store is the only way to get apps onto an iPhone for the general public. They can easily control things there because it's the app store or bust.

<comment><USER23> _It doesn 't help Apple to block a desktop app from their app store because if they do, the developer could release it outside of the dev store._

Safe to say that the ability to release unapproved applications on the Mac is now considered a bug by Apple, and being addressed accordingly.

<comment><USER24> No, it's really not. Could you explain why you think that?

<comment><USER5> See Gatekeeper: [http://support.apple.com/kb/ht5290](http://support.apple.com/kb/ht5290)

Used to be you could install any app you wanted. Now, Gatekeeper is set to deny apps from publishers that haven't paid the yearly Apple tax (aka 'registered' developers which costs $99 a year). Note that Gatekeeper has one additional setting which is app store only. Expect this to be the default in another year or two.

Yes, you can adjust this setting yourself, but most users won't change it. This will kill off most hobbyist development on the Mac and a large percentage of open source apps (GPL apps, the most popular open source license, aren't permitted in the App Store).

<comment><USER6> Any Mac user who uses "hobby" apps knows how to edit their System Preferences.

For people like my parents, who never use any third-party apps and routinely move the entire Safari app to their desktop (I think they think it's a shortcut or something lol), Gatekeeper is useful. I'm just glad they're off PCs now; the number of tech-support calls I get from them has dropped dramatically.

<comment><USER5> I wonder what will happen to apps like Firefox when Apple switches Mac OS to App Store only by default and implement some of the restrictions in iOS in the Mac app store. Restrictions like no Javascript allowed. Sure, apps like Chrome can go the same route as they do on iOS and build a custom Chrome skin atop the slower Mobile Safari engine available to 3rd party apps and always be a slower 2nd place browser. But Firefox? If it's just another slower webkit skin, it's not Firefox. Which is why there's no Firefox on iOS.

<comment><USER25> Assuming none of the rest of the infrastructure'll change - I'd consider working with possibilities as future "when"s impractical enough; a user'll go download Firefox, the standard Gatekeeper denial message'll pop up:

        "Firefox" can't be opened because it was not downloaded from the Mac App Store.
        Your security preferences allow installation of only apps from the Mac App Store.
        Safari downloaded this file today at...

And the user'll either trip over the message and give up in frustration - there _will_ be a class of user who'll visually pattern-match, rather than engage with a meaningful back-and-forth with their computer - or pop into the System Preferences, find Security waiting for them, and off they go.

Fairly banal, but by far and large that's because the assumption that switching the default to the MAS-only option would be a novel attempt at total exclusion shouldn't be true, give or take the major assumption outlined above: not so when the current default's in fact "Mac App Store _and identified developers_ " \- narrowing the locus of trusted sources, then, is a change that should happen independently of how easy it'll be to get an unsigned app running.

<comment><USER5> The default used to be the bottom option which allows all apps. Then Apple switched it to App Store and Publishers that paid Apple $99 with the introduction of Gatekeeper. They'll switch it to App Store only by default soon enough.

I'd wager that when Apple switches it to Mac App Store only by default, lots of open source developers will simply give up on Macs. I was planning on developing for Mac myself. Even bought a second hand Macbook to fire things up. But the way Apple works, I just don't trust that it'll be viable in a couple years. Given Apple's arbitrary application of rules in the iOS ecosystem, I have a dim view of the Mac's future in terms of openness. I decided instead to continue to focus on Windows and expand into *nix and Android.

<comment><USER25> I doubt open-source developers were paying to have their executables codesigned in the first place - I'd assumed in the argument above, at the very least, that the Gatekeeper denial isn't the silent suppression the iOS kernel uses; and on that basis little may as well change for them.

Projecting that Apple'll change both the default position of a radio button _and_ their marginalia and messaging around Gatekeeper is different (as a somewhat more substantial change) from your premise, though.

<comment><USER5> A 3rd party to VLC tried getting VLC in the Mac App Store and then later it was pulled for violating the GPL. VLC had to relicense their whole code base to get in the App Store fully legally. Most open source projects will be unable to do that due to the sheer number of contributors and resistance to hobbling the copyleft license on their code.

Most of us that had been watching Apple had projected that Apple would launch a Mac App store and make it the main place to get Mac software while still keeping clauses in their App Store license that are GPL hostile. That came to pass. As for Gatekeeper, expect that Apple will switch the setting in the next couple years. After all, Mac went from allowing installs of any software by default to restricting unsigned apps, essentially going from the lowest Gatekeeper setting to the middle, with little fanfair and minimal pushback from their userbase. They'll have an easy time taking it the next step as well. It's only really holdouts like Adobe that aren't in the app store that matter at this point. And Apple will likely force them into the App Store to get their 30% cut in the next couple years with the Gatekeeper change.

All of this fits with Apple's core values of making things easy, exercising complete control, and forcing an excessive revenue share from all publishers. It already works that way for iPhone/iPad/iPod apps, music, videos and books. The only holdout is Mac apps and that will happen soon enough. The only folks that usually argue that it won't are the so-called Mac power-users who continue to think that they are critical to Apple's success. This was true for a time when they catered to media professionals. But they don't anymore, nor do they have to. Apple's entire desktop/laptop hardware business accounts for 12% of their revenue and falling. They're a pure consumer company now, not a computer/tech company anymore. There's simply more money in it. That's why their bread and butter OS, iOS, is so completely locked down compared to all of their competitors. There's no reason for them not to follow suit on the desktop/laptop and get their 30% there as well.

<comment><USER25> Your second point is terribly exhaustively induced - I've two nitpicks, though, for the record's sake: there's the fairly low-lying target of whether the poweruser response to the introduction of Gatekeeper suffices to predict the response to any total lockout within OS X: the first was defended on the basis that _it retained the option_ ; the second violates that.

There's also the question of their role: while "power users"'ll make up little direct contribution to Apple's haul, they've forced Apple to expedite the usual inscrutability at times: Apple's been fairly quick with the reassurances after the dual (perceived) fiascoes that were the half-done rehaulings of both FCPX and the-suite-formerly-known-as-iWork.

The question then becomes whether a variable amount of scorn'll sufficiently tarnish the Mac platform as a whole, and whether it retains any inertia to overcome any blip in opinion; that'll depend on what proportion of Apple's Mac owners do care - that hasn't been established specifically for the Mac itself. But it's fairly easy to project along the lines of your note on Apple's dependence on the consumer when accounting for _all_ business: no doubt adoption rates during the past few years've been up to the halo effect, and we only need decide whether the proportions line up - the power users, after all, have always remained, by definition, a minority; they've thus always had a disproportionate amount of influence.

But you're arguing just as well for simply getting rid of their business selling computers: perhaps they could just as well play that chance and feel all the better focused for having fallen into the second. I'm sure there's a surprise within that mold happening within Apple's future; it'd at least give the analysts an impression of sufficient prescience. (Or they'd grant the issue sufficient apathy on that front solely on the basis that their computer lines have reverted back into one of their self-proclaimed "hobby" niches - half the fun of Kremlinology's in tossing away the assumption that every actor must constantly execute, chop-chop.)

(Which takes me back to your first - I _do_ understand that both App Stores don't even so much as consider OSS licences: precisely my claim that "I doubt open-source developers were paying to have their executables codesigned in the first place".)

<comment><USER5> I never claimed they'd get rid of the ability to change the Gatekeeper settings. Merely that they'd switch the default again. Just like before when it went from unsigned being permitted to unsigned not being permitted. Sure, there's an option to change it. But, as it is now, the vast majority of users will never do it. So, yes, you'll have the option to change it as you can now. But with it off by default, it becomes onerous to distribute an app for Mac but not via the app store. Which is as Apple wants it. With all the apps in the Mac app store, Apple can collect their 30% and exclude competition to their own properties like they do on iOS.

FCPX and it's still less-than-previous-version-abilities and the abandonment of the Power Mac for so long are perfect examples of 'power users' being de- emphasized across Apple. Power users and media professionals were a much larger part of Apple's business in the past. They're an extremely tiny part of their business today and, as evidenced by Apple's own decisions and behavior, worth paying a little bit of attention to eventually, but not much.

The main reason for Apple to continue to build laptops and desktops is in service to their iOS and media businesses. Folks still need tools to build apps and put together media.

And as for open source projects having their code signed, LibreOffice, Mozilla Firefox, OpenOffice.org, my own PortableApps.com, etc would politely disagree with you. Being open source doesn't preclude paying to sign or having a business model. But the app store's onerous licensing agreement does preclude some of my apps from ever being able to be offered.

<comment><USER25> I apologize for bringing up the first assumption and running off it - I'd went off with it precisely because you talked about complete exclusion: but of course Apple can do a very well-considered nudge; I'm treading right over false equivocation here, but the question so is always "to what extent?" \- we're happy to consider Android relatively unfettering, despite having a similarly "recessed" option like your projected one, but no doubt we're judging it differently because a phone never needs to hold much promise.

An equivalence to Microsoft - I'm raising a great deal of them only because I believe having everyone rush to emulate Apple's MO has a bit of their exceptionalism rub off - is suggested by your second, though: both have individual consumers, customers dependent on unique line-of-business setups (as to the standard business, media professionals), and independent developers (the last two make up the constituency with an interest in unfettered application installation) in precisely the same proportion - but not the same magnitude. The question, yet again, is in precisely how the proportion represented by "a little bit" turns out to be - and how much that'll be when applied. One has to measure precisely how much's been added back to FCP to the magnitude of their retargeting of the FCP line in the first place to get an impression of their influence. Apple's able to show a great deal of strength, though; I'm simply sizing up the opposing influence.

But neither do I doubt that Apple'd ever deny themselves an opportunity for a bit of bravado: I shouldn't ever be overtly hostile to someone projecting reasoning with overt change and incompatibility for the ideal's sake onto Apple.

Edit: and my thanks to you for the PortableApps as well - I remember lugging around a gaudily pimped-up Firefox (Aqua theme and a Ghostfox-like quick-hide addon, woot woot) on a 512MB flashdrive in middle school, and subsequently realizing that the show of ricer agency can neutralize anyone's ability to reasonably judge taste. A fairly good life lesson to be had early while getting to terms with a teenager's first pecking order.

<comment><USER5> No apology necessary, just a typical online missing-a-few-blanks-and-filling- them-in-ourselves event. :) It's true that Android has the ability to 'side load' and it is off by default, but phones and PCs are different animals. So, it's better to compare it to Windows which permits running even unsigned apps by default, though it does black the screen and show a warning box with a big red exclamation point.

Realistically, I think the Mac laptops and desktops will continue along the 'consumer' line of thinking in terms of features and functionality. Apple will likely set Gatekeeper to Mac App Store only by default within the next release or two of Mac OS X. Users will be able to change it, of course, but it will still have the desired effect of making publishers feel like they have to sell through the App Store and give up 30% of their revenue to Apple (and also abandon many of their pricing models since the App Store doesn't support variable upgrade pricing, unfortunately).

Most Apple users won't even know they can get apps outside of the App Store at that point, similar to how most Android users don't know. Similarly to Android, of course, there will be some power users that know and make use of that feature. Most Mac OS X users will be completely unaware of the fact that any of this happened or that their options have been limited, though, the same way most iOS users are unaware Apple prohibits third party browsers (unless they're just a skin on hobbled Mobile Safari), SMS clients, etc.

Personally, I disagree with the path Apple has forged the last few years. They make pretty good hardware and were the first company that really 'got' mobile music (and the fact that it needed good hardware and software - both on the device and the connecting PC). I have an original iPod Mini I got and later hacked a 16GB CF card into and ran Busybox on. I even have an old Mac Classic sitting in the closet that I'll pull out and put shufflepuck on at some point. But I likely won't buy anything from Apple ever again at this point. And I won't develop anything for a platform whose owner operates the way and has the level of control that Apple does. Both of which make me a bit sad.

Glad you like PortableApps.com and it's helped you out. We're still chugging along. If you're so inclined, give it an install to your cloud drive (Dropbox, SkyDrive, Google Drive, etc) and you can run your apps from there and sync them among your Windows machines. You can even run them under Wine on *nix or one of the Wine equivalents on Mac (CrossOver, Wineskin, WineBottler, PlayOnMac).

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> Oh right, THIS is why it's not a good idea to use a system where a single corporation (and one predisposed to control-freakery at that) gives itself veto power over what your device can and cannot do.

(not that "everybody go buy a Nexus 5" is the answer either. The only way to keep these corporations in check is a competitive platform marketplace with considerably more than two players. Go buy a Lumia, a Jolla, a Firefox phone, a Tizen phone...support diversity, kids)

<comment><USER11> Why not everyone go buy a Nexus 5? It looks open as phones go, you can just root it with adb[0]. As long as you can root the phone and swap in your own OS I think Google's phone is as good as any other.

[0] [http://wiki.cyanogenmod.org/w/Install_CM_for_hammerhead](http://wiki.cyanogenmod.org/w/Install_CM_for_hammerhead)

Edit: I didn't read your post carefully enough. Yes, it would be wise to assume that Google will eventually become malicious and try to future-proof by supporting entities making comparably liberated phones.

<comment><USER26> thanks for the edit. Indeed, my wariness of Google has increased as they have moved more and more of Android out of AOSP and into closed code that ties so closely with the Google mothership...

<comment><USER11> Yes I actually feel the same, they look like they are plotting something (for lack of a better description). Locking down the OS would be a strong indicator for a future walled garden scheme and if it comes to that I am definitely done with them just like I am with Apple.

</comment></comment></comment></comment><comment><USER27> This isn't what is what is happening here at all, but it gave me an idea. What if some person or organization with a lot of influence, like Apple, shorted on bitcoin, then banned it or did something to affect it's price.

This can work the other way around too, encouraging bitcoin use to increase it's value, after buying a bunch of it.

<comment><USER28> I'd imagine it'd go the same as the thousand other incidents of people trying to game commodity/currency markets.

[http://en.wikipedia.org/wiki/Ulysses_S._Grant_presidential_a...](http://en.wikipedia.org/wiki/Ulysses_S._Grant_presidential_administration_scandals#Black_Friday_Gold_Panic_1869)

<comment><USER11> Looks like Fisk and Gould were relatively unaffected by it, the country at large suffered a great loss, and nobody was punished for it.

My word, history does repeat itself, they were just shy a government handout and a multi-million dollar skiing trip.

</comment></comment></comment><comment><USER29> Welcome to the wonderful world of feudalized devices.

Relevant: [http://boingboing.net/2012/08/23/civilwar.html](http://boingboing.net/2012/08/23/civilwar.html)

</comment><comment><USER30> Off topic, but:

>>Bitcoin skeptics don't see the proof-of-work from mining as a good reason for there to significant value in the currency.

Do Bitcoin proponents see this as a good reason for the currency to have significant value? Why?

<comment><USER3> Proof-of-work doesn't create the value; it enforces the rules of the protocol via incentives and consensus (essentially, one CPU = one vote). Any value is created entirely in people's heads. Whether that's a good or bad thing is up for debate.

</comment></comment><comment><USER31> I've been a vocal supporter of most of Apple's policies over the years but they really are on the wrong side of history with this one.

Apple should embrace change (think different!) by accepting bitcoins themselves and let related innovation thrive on the App Stores. In the end it's all about the digital wallet which means more sales of mobile devices.

So please, dear Apple understand that the decentralized Internet of money is here. It won't go away so better get all in!

<comment><USER32> Such dogma on Apple's part, taken to extreme, devoid of common-sense: the strangling innovation is a great way to push apps and their developer entourage to other platforms. There's curation and then there's disproportionate culture of "No."</comment></comment>


Facebook's Earliest Rival, Why It Failed.  - <AUTHOR> http://www.sociableblog.com/2010/10/12/facebook-earliest-rival-why-it-failed/#more-6158

<comment><USER2> Amherst College had a web-based social network called "planWorld" (after VAX .plans, which it replaced) starting around 1999. I know Grinnell had something similar. I have to imagine that other colleges did too.

Amherst also had the DailyJolt, a web forum founded around 1999, and that one actually expanded to several other campuses.

I suspect that FaceBook became dominant because it had a.) the right features b.) at the right time c.) expanding to the right places d.) in the right order.

Sites like Friendster died because they missed critical features, namely the ability to stay up for a reasonable amount of time under load. Friendster was also good for making friends (or at least recording them), but didn't provide very much for you to do with them.

Sites like planWorld - and LiveJournal, for that matter, which was far better and more dominant than FaceBook in 2004 - failed because they were too early. They couldn't get a critical mass of people to explode in popularity, because social networking was still a niche activity, popular among geeks and nerds but not among the general public.

Sites like Campus Network (or planWorld, again) failed because they failed to expand. As the article says, Campus Network was way more popular among Columbia students, and FaceBook had to struggle to make inroads at Columbia. And among Amherst students who attended between 1996 and 2005, planWorld still tends to be more popular than FaceBook.

Sites like MySpace failed because they tried to expand in the wrong order. MySpace captured the 20-something music scene, and then the high school market. But college kids don't do what high school kids are doing, high school kids do what college kids are doing. And (at least in technology) kids don't do what their parents are doing, parents do what their kids do. FaceBook had perfect positioning to take over the rest of the market, because high school kids do what college kids do, and college kids eventually graduate and become 20-somethings, and then parents do what their kids are doing. MySpace had no room to expand once FaceBook captured the college market, because they lost the high schoolers to FaceBook, and then they had no beachhead to grab the parents.

It kinda reminds me of what Google told us during orientation: Google succeeded because they had the right idea, at the right time, with the right technology and the right people, in the right place. And without any of those elements, they would've failed miserably. I suspect a lot of startups are in the same boat.

</comment><comment><USER3> The original article that this is taken verbatim from is at <http://www.slate.com/id/2269131/></comment>


Concrete Airmail Arrows: Accessing the Bay Area's Unique 'Double Arrow' Set - <AUTHOR> https://99percentinvisible.org/article/concrete-airmail-arrows-accessing-bay-areas-unique-double-arrow-set/ <comment><USER2> Shame these are unmaintained as a historic landmark. I bet it would completely change how kids see the world to understand that people used to rely only on visual clues to navigate not too long ago.

It's one thing to read about it in a textbook, it's another to be able to see and touch it.

</comment><comment><USER3> The key to Superman's arctic Fortress of Solitude is disguised as a yellow aviation arrow.

So, yeah. One of these.

[https://en.m.wikipedia.org/wiki/Fortress_of_Solitude](https://en.m.wikipedia.org/wiki/Fortress_of_Solitude)

<comment><USER4> Holy aviation arrows, Batman, you are right!

You know, your comment was a good lesson for me. At first glance I thought to myself, "This is pretty weird and how can it possibly be true? I'd better downvote the comment right now!"

Fortunately, I came to my senses and actually clicked the link, and sure enough, Superman's key to the Fortress really was a yellow aviation arrow (or disguised as one).

I think you have taught me to not jump to conclusions quite so fast. Thank you for making this interesting connection!

</comment></comment><comment><USER5> To me they look smaller than I imagined. Undoubtedly they were set away from built up areas but have since been encroached on.

I guess they also flew much lower than planes do now, even if towers served as indicators for the arrows.

<comment><USER6> From Wikipedia: "Many arrow markings were removed during World War II, to prevent aiding enemy bombers in navigation, while 19 updated beacons still remain in service in Montana."

You can browse photos and Google maps here:

[http://www.dreamsmithphotos.com/arrow/contrib_photo.html](http://www.dreamsmithphotos.com/arrow/contrib_photo.html)

Doesn't look like there are any towers that have survived or been preserved, unfortunately. Noted in the article that they were dismantled in WWII for steel.

I was looking for towers to learn if they lighted the arrows at night, in addition to the beacon. Just curious.

<comment><USER7> In my area (the southwest), it's not unusual for modern municipal airports to have their standard airport beacon mounted on a tower that was originally installed for an airmail route beacon. Sometimes the tower has been moved, but sometimes it sits on the original base, usually sans arrow as it seems that intermediate fields (which were often later turned into municipal airports) didn't always have an arrow installed. My old home of Socorro, N.M. has such an example, and although I have not been able to properly confirm this it appears that the airport beacon there is actually the original airmail route beacon with lenses and electrics replaced. It nicely matches the drawings I've seen of the beacon lights. Many, even most, of the municipal airports in the southwest date back to CAA intermediary fields often placed along beaconed air routes, so keep an eye out in AZ, NM, TX. I'd guess this is true of other fairly rural states as well.

In Grants, N.M. there is a particularly interesting example at the municipal airport. There, there's a fully intact and nicely painted generator hut and beacon tower. It's been restored and is now operated by a historic society. Unfortunately, it had to be moved from its original location on a nearby hilltop into town because the actual beacon once located at the present site of Grants airport was removed many years ago. Still, one of very few I know of that is being preserved as a museum piece.

To my knowledge the arrows were not lit. In many places there are beacons without arrows, my understanding is that this was done because, at night, the next beacon was supposed to be visible by the time you flew over the previous beacon so that you knew which direction to head. During the day the arrows could be placed less frequently, generally only at turns, since pilots could see the direction and the towers in between would serve as confidence markers that they were on course.

<comment><USER3> Wow. I almost learned to fly at KONM ... didn't know that the beacon was originally an airmail tower. I will ask my (former) neighbor and original of the current Socorro Civil Air Patrol wing. Thanks for posting this!

</comment></comment></comment></comment><comment><USER8> Found one near where I grew up. It was on a airmail route run by Pitcairn Aviation between Atlanta and New York City. Pitcairn was sold to a firm that became Eastern Air Transport, which eventually became Eastern Airlines.

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

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

</comment><comment><USER9> From airmail to email, the bay area has a rich communications history.

From the Wikipedia page on Airmail: "Starting in 1903 the introduction of the airplane generated immediate interest in using them for mail transport. An unofficial airmail flight was conducted by Fred Wiseman, who carried three letters between Petaluma and Santa Rosa, California, on February 17, 1911.[5]

The world's first official airmail flight came the next day, at a large exhibition in the United Provinces of Agra and Oudh, British India."

[https://en.m.wikipedia.org/wiki/Airmail](https://en.m.wikipedia.org/wiki/Airmail)

<comment><USER7> San Francisco's position at almost the most extreme west point of the country has given it a lot of interesting distinctions in aviation history. Crissy Field, now a rather pleasant park just off the Presidio, was once an army airfield and the ending point of the first transcontinental flight completed in one day, dawn to dusk. There's a small plaque there commemorating the event. For many ears in the early 20th century it was a stopping point for air mail flights. A few of the buildings along there, now under NPS management, are old hangers from its previous use. Treasure Island also used to be a major seaplane airport, even after aviation use of the island itself ended (it had once been slated for the location of San Francisco International Airport, as a bit of trivia).

<comment><USER10> Most extreme west point is actually in Washington state (Cape Alava).

</comment></comment></comment><comment><USER11> 'Arrows on the ground to guide aeroplane pilots.' might be a better title.

The arrows are concrete, though they were built in 1920s with metal too.</comment>


Ask HN: Offline Marketing Strategy For Smart Phone Apps? - <AUTHOR>

I'm building an app which helps golfers network with each other and pairs them up for Tee times. I'm having hard time coming up with suitable marketing approach. With my customer development hat on, I'm thinking about approaching golf courses, and having them push this to their club members. The challenge is for a given golf course say 500 members / month - with 30% of them using iOS and 10% (optimistic scenario) initial interest - I'm already down to 15 members / month. Ideally with infinite resources - I would support all smart phones, and cover multiple golf courses in a city. But with given resources and time, I need to focus on best way to take-off. I can't be the only one trying to use offline marketing for building customer base.<p>How did four-squre get their first 1000 users. Did they collaborate with the businesses from the get go? What are your experiences for building a smart phone app which required offline marketing? How did you get your first 1000 users? Any advice would be greatly appreciated. <comment><USER2> First of all, have you validated this app with your market? Have you actually approached executives and golfers to see if they would use this app? No amount of strategy will overcome a lack of desire or need, so if you haven't done that yet, I'd make that my first priority before sinking a bunch of time & money into anything else.

Assuming the idea is valid, I'd concentrate my efforts on a single country club. Not a public course, but a country club. Golfers that are serious about using golf as a networking tool probably belong to a club (again, something to validate). You'll obviously need to get the club to sign on regardless whether you're pitching them directly or not.

Once you've got the club's permission, there are a number of things you could do:

You could partner with the club and offer an exclusive (but limited) co- branding opportunity. So the app would be a "service" that the club offers to help members network. This would add credibility to the app and make members more likely to take interest in trying the service.

You could negotiate a deal with the pro shop to give away discounts or free memberships to the app with purchases.

Anyhow... you get the picture. My point is to start with a focus, don't spread yourself too thin. If the app takes off, you can always expand.

Think about Facebook's strategy. They started out just focusing on one school and then branched outward to other ivy league schools before finally branching out to all colleges and then the public.

<comment><AUTHOR> Thanks - very thoughtful response! I have been burnt before, so validation is definitely #1 priority for me. I'm still in the wire-framing phase, because I at-least want to take these screenshots with me when I talk to the golf courses.

But my problem is that of segmentation - I don't have the bandwidth to support both iOS and Android at the same time, which cuts off a big chunk of audience.

Since the core of the app is networking - supporting the major platforms is quite important. But hey it is what it is. I've gotta start from somewhere!

<comment><USER2> What do you mean when you say you don't have the bandwidth to support both iOS and Android?

If you're targeting businessmen, I think cross-platform is pretty important. Most executives are likely using Blackberry and Android. iOS is still trailing in the business sector last I checked.

If you use a cross-platform SDK you can cover your bases and not have to worry about it. Something like Phonegap or Corona could dramatically increase your likelihood of adoption.

<comment><AUTHOR> I agree with you. By band-width I meant the time and resource I have to devote to this idea. I have a full time job, and in evenings, I have been taking programming classes. So, I didn't think I could support cross platform from the get-go.

Your responses and suggestions are right on the money. What's your background and interest areas?

</comment></comment></comment></comment><comment><USER3> Recommendation: Release it as a beta/working product and tell them they are the privileged few to get it and that their usage and feedback will decide the future of this product that might somebody make millions of dollars.

People like to feel important and people like to support that seem to have a potential to rise.

Anyway, spread it selectively among golfers like this till you have around 200 users. By far the best people to try and approach for you might be either the gold course managers or better still, get the caddy's who work there your app and tell them that they can give it out to only 5 people etc. They will slowly build up your user base with their excitement of the product (if they are excited and it's relevant to them). These people, due to our age, experience and optimism will take this as a privilege and will be able to to talk passionately about it. That's exactly the behavior you want from your first 100 users. Also, watch what your users do very carefully and take the time out to talk to them. No shortcuts.

<comment><AUTHOR> Thanks Svetha for your input and encouragement! My dilemma is to build it on iOS or Android? But eitherways - I've gotta start. For me next step is to finalize the wireframes and approach the golf courses!</comment></comment>


Teasing Out the Bang for the Buck of Inference Engines - <AUTHOR> https://www.nextplatform.com/2018/10/12/teasing-out-the-bang-for-the-buck-of-inference-engines/ <comment><USER2> Xilinx is certainly doing some very interesting stuff with Everest.

But to be honest I don't see where all the hype (and funding) for inference accelerators is coming from. It think that many people overestimate the difficulty of making an accelerator that does high performance 8 bit math - google has done it (TPUv1), tesla has done it (unnamed custom silicon), nvidia has done it (nvdla), Xilinx has done it, ...

I can't see inference accelerators becoming anything but commodity in a few years.

<comment><USER3> I think most of the excitement is probably that it isn't something strictly Intel / AMD can do.

Which is pretty disruptive in the semi space.

The last times we had problem spaces that weren't economic to add to CPU (graphics, machine learning / GPGPU), a whole lot of value was captured by different players.</comment></comment>


How is java being used in today's web apps? - <AUTHOR> <comment><USER2> For implementing backends which provide REST APIs.

</comment><comment><USER3> back end</comment>


The Road to 2M Websocket Connections in Phoenix - <AUTHOR> http://www.phoenixframework.org/v1.0.0/blog/the-road-to-2-million-websocket-connections <comment><USER2> Great job Phoenix team! I wonder how much of this wouldn't even be possible if not for the great BEAM platform and Cowboy web server.

Whatsapp famously works with 2m connections on a FreeBSD box (this number is old, I bet they've beaten that number). [http://highscalability.com/blog/2014/2/26/the-whatsapp- archi...](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture- facebook-bought-for-19-billion.html)

I wonder whether these two cases are in any way comparable. Different stacks, different machines, different test. The only similarity being BEAM/Erlang used as a platform. Speaks well of its scalability!

<comment><AUTHOR> None of it would be possible without BEAM and Cowboy :) Cowboy is a huge driver for our great numbers. It handles the tcp stack and websocket connections for us. As I said elsewhere in this thread, we are doing more than just holding idle WS connections open, but we're standing on the shoulders of giants as far as cowboy and erlang are concerned.

</comment></comment><comment><USER3> We've been using Phoenix for several applications for over a year. The channel functionality is so easy to use and implement. High recommend people checking this out: [http://www.phoenixframework.org/docs/channels](http://www.phoenixframework.org/docs/channels)

<comment><USER4> I'd also recommend the Programming Phoenix book, it's still in beta but the chapter on Channels just came out:

[https://pragprog.com/book/phoenix/programming- phoenix](https://pragprog.com/book/phoenix/programming-phoenix)

</comment></comment><comment><AUTHOR> My ElixirConfEU keynote gave a high-level overview of the channels design for those interested - quick jump to place in presentation: [https://youtu.be/u21S_vq5CTw?t=22m34s](https://youtu.be/u21S_vq5CTw?t=22m34s)

I'm also happy to answer any other questions. The team is very excited about our channel and pubsub layers progress over the last year.

</comment><comment><USER5> If you listen on multiple ports, you can get way more than 64k connections per client. If the workload is mostly idle, tsung should be able to manage quite a few connections too.

<comment><AUTHOR> We'd like to explore a private network so we can get away with more than 64k per client, as it starts to get expensive spinning up 50 servers whenever we want to test. Unfortunately, the instances that were lent to us came with no way for us to assign additional IPs.

<comment><USER5> You don't need multiple IPs, tcp connections are a unique 4-tuple: {ClientIP, ServerIP, ClientPort, ServerPort}. If you add more ServerPorts, you can re-use the client ports. Now, if you want to test past 4 billion connections, you need more IPs. :)

<comment><USER6> > You don't need multiple IPs, tcp connections are a unique 4-tuple: > {ClientIP, ServerIP, ClientPort, ServerPort}.

Sometimes someone throws something out so casually and yet you realise the innate sense of what they just said, I literally stopped with coffee halfway to my mouth.

I'd never have thought of doing it that way.

<comment><USER5> I may have connection tested a few things in the past ;) If you're benchmarking with tsung, it's nice, because it has hooks to let you pick the client port when making the connection; you'll probably need this, because the OS default assignment algorithms tend to get it wrong with this much stuff going on.

</comment></comment></comment></comment></comment><comment><USER7> I'd be interested in benchmarks vs other similar frameworks, for the same use case. These had json/db queries benchmarks however Phoenix lags behind (will be at the top soon?) [https://www.techempower.com/benchmarks/previews/round11/](https://www.techempower.com/benchmarks/previews/round11/)

<comment><USER8> Take a look at source code. Phoenix in question

1) outdated, version used is really really old (0.8 or so)

2) Database pool set to really low value unlike other participants (~10x lower)

3) Configured to do many things other frameworks skip, like generating csrf token

All these points were fixed already but, most likely, new results will go to Round 12

<comment><USER7> ok. will see round 12.

But why did you downvote my comment? I was just reporting a fact, a benchmark that was performed by a third-party. It's not like I was voicing a weird opinion or fabricating truth.

<comment><USER8> I didn't (nor have such rights nor intention). Also, valid question imo. Btw, tested it [old version] locally with a single change - set pool size to 256 (similar to other frameworks). Result: ~10x performance boost

<comment><USER9> This is par for the course on the TechEmpower benchmarks. Certain technologies' benchmarks have always been relentlessly optimized while others are left to "the community" which means you can submit PRs, but they'll likely be rejected even if they reflect the usual deployment patterns for a high proportion of users of the language/framework being represented.

<comment><USER10> that's why this benchmark seems irrelevant.

</comment></comment></comment></comment></comment></comment><comment><USER11> I've been using elixir/cowboy/Phoenix for the past few months and it's been great. It seems like the elixir ecosystem is still being built out but there are a lot of erlang libraries to use also.

</comment><comment><USER12> I'd be interested in seeing this same performance benchmark run against various other OSes.

In particular DragonflyBSD since it has a lockless network stack.

And FreeBSD for good measure given that Whatsapp runs an Erlang/FreeBSD stack and has documented 2-3M connections themselves.

<comment><AUTHOR> We were shocked how well stock ubuntu performed under these tests. With the stories of freebsd tuning, we expected to hit an OS ceiling, but other than a dozen shell script lines setting some sysctrl limits, everything else was stock. I would also be very interested in how other OS's perform.

</comment></comment><comment><USER13> This is really cool, I'm hoping to see more small companies experimenting with Phoenix. It seems like a great tool.

</comment><comment><USER14> Is it a relevant benchmark to open 2M connexions without doing anything in it?

<comment><AUTHOR> I was worried some might not make it that far into the post and come away with that thought, but such is the nature of long-form prose :). This is more than idle WS connections. Every channel client connects to the sever (via WS), then subscribes via our PubSub layer to the chat room topic. Once we connect all 2M clients, we use the real chat app to broadcast a message to all 2M users. Broadcasts to out to all WS clients in about 2s. 2M people in the same chat room might not be a real-world fit, but it stressed out PubSub layer to its max, which was one of the goals for these tests. We were actually shocked at how well broadcasts hold up at these levels.

<comment><USER15> What this benchmark shows is the lightweightness of the memory needed per websocket. 2M users is really impressive.

2M users per machine is great if they are mostly idle. This is the use case of WhatsApp, and their stats are[1]:

> Peaked at 2.8M connections per server

> 571k packets/sec

> >200k dist msgs/sec

Not every app is meant to have mostly idle users. Can a real-time MMO FPS be done in phoenix is the question (lets limit each user's neighbourhood to the 10 closest players).

I'd be very interested in the other corners of the envelope for phoenix: A requests/second benchmark over websockets, with the associated latency HdrHistogram, like [2]

[1] [http://highscalability.com/blog/2014/2/26/the-whatsapp- archi...](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture- facebook-bought-for-19-billion.html)

[2] [http://www.ostinelli.net/a-comparison-between-misultin- mochi...](http://www.ostinelli.net/a-comparison-between-misultin-mochiweb- cowboy-nodejs-and-tornadoweb/)

<comment><USER16> I am a very happy user of Phoenix myself, and also a MMO game programmer, and unfortunately I can say with confidence that you won't implement a real-time MMO FPS on top of Phoenix channels any soon.

Not because of Phoenix itself, but because all modern lag-compensating techniques rely on specific properties of UDP that are not implementable over TCP (and thus not over Websockets or HTTP long poll, which are the currently supported Phoenix Channel transports).

Not to diminish the value of Phoenix: the framework is really pleasant to use both on dev side and ops side. And you could use it today to implement the server-side of most games, even some "massive multiplayer" ones, as long as latency is not your primary concern.

<comment><AUTHOR> You are right our default transports (WS/LongPoll) are not well suited for FPS requirements, but just to be clear transports are adapter based and you can implement your own today for your own esoteric protocol or serialization format. Outlined here: [http://hexdocs.pm/phoenix/Phoenix.Socket.Transport.html](http://hexdocs.pm/phoenix/Phoenix.Socket.Transport.html)

The backend channel code remains the same and the transport takes care of the underlying communication details.

</comment></comment></comment></comment></comment><comment><USER17> the other day i set up hot code upgrades (in a single node, production instance) with exrm and phoenix. it was a breeze and took about 30 minutes of reading and setup. and now i can upgrade the backend while all the websocket connections stay running. so cool!

</comment><comment><USER18> Now that you can buy servers in tiny linear increments, it seems more interesting (but less headline-y) to talk about KB per connection or CPU per connection. It looks like this is about 41KB per connection.

For comparison, I checked my not-very-optimized go server, and it looks like (based on VSZ value) to use 25KB per connection in go, with 43KB per connection used by nginx (to provide SSL termination).

<comment><AUTHOR> Like I highlighted elsewhere, did your Go server setup a separate multiplexed process for the PubSub channel and track the PubSub subscribers on each client connection? Comparing the client size to raw WS connections isn't accurate in this context. Horizontal scaling is nice, but you also have to consider the overhead in broadcasts that now are distributed over dozens/hundreds of nodes vs a handful of large nodes.

<comment><USER18> I track the pubsub subscribers on each client connection, but I'm not sure what you mean by a multiplexed process for the pubsub channel.

Depending on your traffic patterns, considering the broadcast activity is potentially important, and then you might worry more about CPU than RAM.

I use redis myself, but gnatsd or redis cluster may help with scaling the pubsub part of the system.

</comment></comment></comment><comment><USER19> Great article! One minor nit: When explaining the bag vs duplicate_bag thing, it says

> _The difference between bag and duplicate_bag is that duplicate_bag will > allow multiple entries for the same key._

bag also allows multiple entries per key. After reading the ETS documentation, it appears that duplicate_bag allows the same object instance to appear as a value for a key multiple times, whereas bag only allows an object instance to be added once to a key (e.g. so if you add the exact same object instance to the table using a given key, bag will only end up with one value for the key, but duplicate_bag will happily have many identical values for that key).

The following sentence is still fine:

> _Since each socket can only connect once and have one pid, using a duplicate > bag didn 't cause any issues for us._

</comment><comment><USER20> I love this kind of stuff. Awhile back I attempted to do similar benchmarking with Pushpin: [http://blog.fanout.io/2013/10/30/pushing-to-100000-api- clien...](http://blog.fanout.io/2013/10/30/pushing-to-100000-api-clients- simultaneously/)

Like the Pheonix test, this tested broadcast throughput. However we couldn't push more than 5000 messages per second out of a single EC2 m1.xlarge instance otherwise latency would increase. My theory is that we were hitting the maximum throughput of the underlying NIC, causing packet loss and requiring TCP to retransmit (hence the latency). At some point I want to try adding multiple virtual NICs to the same EC2 instance and see if that helps.

<comment><USER21> ec2 instances (at least in ec2 classic) indeed have a limit of ~120K packets per second. I don't know if this is per NIC, so I would be interested in seeing your results.

</comment></comment><comment><USER22> am i reading this correctly... 83gb of ram in use for 2m connections? seems like a lot of overhead.

i have achieved 500k concurrent connections using atmosphere, consuming around 10gb of ram.

<comment><AUTHOR> That's correct. We have not made any attempt at optimizing connection size yet, so there should be room to trim this down. But honestly, I'm thrilled with the numbers as is. This box on rackspace will run you $1500/mo, which is going to be peanuts for a company requiring this kind of scale, but the more we can trim down the connection size the better.

<comment><USER23> > which is going to be peanuts for a company requiring this kind of scale

That depends. Two million connections from people in an e-commerce site is a lot, but two million connections for a side-thingy like some analytics/ads/background-job-whatever doesn't have to be that much, especially if you consider 3rd party code.

<comment><AUTHOR> Cases will vary, but if you have _2 million_ active users at a time and can't cover $1500/mo, then I'm not sure what your options will be. Along these lines, I'm really excited about what kinds of creations Phoenix will enable exactly because the kind of scale it gives you for current hardware. I think we'll see disruptive applications/services come out because of what you can get out of a single machine, so I find stressing price as not affordable in this context really bizarre.

<comment><USER23> I understand, I do like the idea of Phoenix, and it is definitely great to be able to keep 2M connections open at all.

I'm just wondering where is the per-connection overhead going into. Is there some inherent limitation of the WebSocket protocol that forces the server to keep large buffers or something? Not trying to bash on Phoenix, I'm just genuinely interested in what is the lowest possible overhead one could achieve while keeping an open WS connection.

<comment><USER24> Doing some rough math and my limited understanding of linux network internals, it's about 40KB per connection in this benchmark. I know that cowboy is going to require ~4KB or so per connection. Consulting a local ubuntu install, the default minimum buffer sizes in TCP will be at least 4KB each (2* for read and write), but by default 16KB each, and by default the max goes to 1.5MB or so each. This is required for TCP retransmits and such. If you have clients on shoddy connections or see packet loss, your memory could skyrocket on you. I remember reading of a case where someone had a service die despite memory overhead of 33% when the TCP packet loss rate went up (still under 1%), but it caused their buffer sizes to grow large enough to run out of memory.

So that's 8KB (will be higher with more usage) for TCP buffers in the kernel, 4KB or so for cowboy, and 28KB or so left for various other bits of the system when amortized per connection.

</comment></comment></comment></comment></comment></comment><comment><USER25> isn't there a 65k limit of number of open ports on the TCP stack??

<comment><USER24> As noted above, TCP connection limits are only on a unique 4-tuple of local- ip, local-port, remote-ip, remote-port.</comment></comment>