HTTP/2.0 – Please admit defeat - <AUTHOR> http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0815.html <comment><USER2> Related [1]:

        Wired: How has your thinking about design changed over the past decades?

        Brooks: When I first wrote The Mythical Man-Month in 1975, I counseled
        programmers to "throw the first version away," then build a second one.
        By the 20th-anniversary edition, I realized that constant incremental
        iteration is a far sounder approach. You build a quick prototype and
        get it in front of users to see what they do with it. You will always
        be surprised.

[1] [http://www.wired.com/2010/07/ff_fred_brooks/](http://www.wired.com/2010/07/ff_fred_brooks/)

<comment><USER3> I'm surprised that people still believe the Mythical Man-Month. As mentioned it was written almost 40 years ago.

It was revolutionary at the time but people have moved on and found many improvements to the original and also outright mistakes.

(As the author seems to have acknowledged when releasing a new improved iteration of his book.)

<comment><USER4> > I'm surprised that people still believe the Mythical Man-Month. As mentioned > it was written almost 40 years ago.

That hardly means that what it has to teach isn't still valid. Admittedly, I've only read a few chapters in it, but the central point that throwing more man power at a late project only serves to make it later, is at least as relevant today as when the book was first published.

> It was revolutionary at the time but people have moved on and found many > improvements to the original and also outright mistakes.

Could you be more specific?

> (As the author seems to have acknowledged when releasing a new improved > iteration of his book.)

So, do your points above refer only to the first edition of the book then?

<comment><USER3> > throwing more man power at a late project only serves to make it later

This is only part of the book. And as per this thread there's a lot more to the book . IE we are specifically talking about it's comments on prototyping which the original OP mentioned in their email.

It's been years since I read it, but I'll toss in this review with their points -[http://www.goodreads.com/review/show/882155551?book_show_act...](http://www.goodreads.com/review/show/882155551?book_show_action=true&page=1)

To me, to believe one persons opinionated book from 40 years ago as relevant today is just plain wrong. Even things like the way science was done back then is in questionable today.

Systems they developed will be improved on, technology and societal change will make specifics no longer totally accurate and one person won't get an entire book right.

</comment></comment></comment></comment><comment><USER5> I think this ([http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/...](http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/0816.html)) follow-up makes a valid point:

> _In the old days we had different protocols for different use cases. We had > FTP and SSH and various protocols for RPC. Placing all our networking needs > over HTTP was driven by the ubiquitous availability of HTTP stacks, and the > need to circumvent firewalls. I don't believe a single protocol can be > optimal in all scenarios. So I believe we should work on the one where the > pain is most obvious - the web - and avoid trying to solve everybody else's > problem._

If we're not careful, we're just going to end up cycling back around again and find ourselves 20 years in the past.

That said, I do think to some extent "that ship has sailed". The future of network programming seems like it will be "TCP --> HTTP -(upgraded connection)-> WebSockets --> _actual_ application layer protocol". See, for example, STOMP over WebSockets. While it is annoying that this implies we've added a layer to the model, it's hard to argue with the real-world portability/ease of development that this all has enabled.

<comment><USER6> The importance of firewall punching can't be overstated. There are plenty of end users in workplaces or on other people's wifi who find that all outgoing ports other than 80 and 443 are blocked. Yes, this is incredibly stupid, but they're not going to do anything about it.

<comment><USER7> So what you're saying is that since incompetent firewall admins have blocked all applications except the web and no amount of reason can convince them to do otherwise, all applications of the future should be tunnelled through HTTP.

And thus naturally HTTP must be made to accommodate for all those applications.

You may think that makes sense, but you don't create something as long-lasting as internet-scale architecture based on hacks around incompetence.

Besides, if that's the path we're walking, DPI-based firewall with HTTP-level application firewalling will become the new norm, and we've gotten nowhere further. Except we now have a even bigger mess to work with.

While the OSI-model may be going a bit over board for some aspects, making all future application-protocols be a squashed through HTTP is madness. This thinking is of the same quality and mindset as of PHP developers.

<comment><USER8> > you don't create something as long-lasting as internet-scale architecture > based on hacks around incompetence

The right half of your brain is wired to the left half of your body (and vice versa). That's just the standard, go-to, basically harmless example of stupidity in the design of long-lasting systems.

From [http://uncyclopedia.wikia.com/wiki/Unintelligent_Design](http://uncyclopedia.wikia.com/wiki/Unintelligent_Design) :

> Unintelligent Design is the theory that the world was designed by some > higher power, but this higher power did a piss poor job at it. There are > many theories as to how the universe could have been so stupidly and half- > heartedly spilt into existence.

Or from the slightly more serious [http://en.wikipedia.org/wiki/Unintelligent_design](http://en.wikipedia.org/wiki/Unintelligent_design) :

Your optic nerve originates at the front of your retina and pierces through it, instead of more sensibly originating at the back:

> The retina sends electrical signals to the brain through the optic nerve and > people see images. The optic nerve, however, is connected to the retina on > the side that receives light, essentially blocking a portion of the eye and > giving humans a blind spot. A better structure for the eye would be to have > the optic nerve connected to the side of the retina that does not receive > the light, such as in cephalopods.

You stupidly breathe through the same tube you eat and drink with, causing a staggering number of unnecessary deaths:

> If the [pharynx and larynx] were not connected and did not share a portion > of their travel paths, choking would not be an issue, as it isn't for most > other animals in the world.

<comment><USER9> I think people are missing your point: Human beings seem to be built based on hacks around incompetence, yet we've made it for quite some time, it's not a great point but nevertheless makes sense.

<comment><USER8> That's one of two points. Indeed, humans are a much, much longer-lasting system than the internet. But you can also think about why these kinks in the design of living things arose in the first place; as wikipedia nicely points out, a lot of glaring mistakes in one animal work the way you'd expect in other animals. The "mistakes" arise because they're the fastest way to produce a desirable result, and they persist for great periods because making changes to a working system is very hard. In a certain sense, history does show that adding hacks on to the "outside" of a working system, so that it stays working at all times, can be a superior strategy to trying to revamp the whole thing in an elegant manner.

</comment></comment></comment></comment></comment></comment><comment><USER10> I am so glad there is at least one prominent name advocating this line, because I feel like this quote from another IETF discussion is becoming more and more relevant:

> Is there an IETF process in place for "The work we're doing would harm the > Internet so maybe we should stop?" \- [http://www.ietf.org/mail- > archive/web/trans/current/msg00238....](http://www.ietf.org/mail- > archive/web/trans/current/msg00238.html)

HTTP/2.0 has been rammed through much faster than is reasonable for the next revision of the bedrock of the web. It was always clearly a single-bid tender for ideas, with the call for proposals geared towards SPDY and the timeline too short for any reasonable possibility of a competitive idea to come up.

There has never been any good reason that SPDY could not co-evolve with HTTP as it had already been doing quite successfully. If it was truly the next-step it would have been clear soon enough. All jamming it through to HTTP/2.0 does is create a barrier for entry for similar co-evolved ideas to come about and compete on even footing.

<comment><USER11> PHK has always been skeptical of HTTP/2 & SPDY

He wants radical change in the protocol but when given the opportunity submitted a (by his own admission) half baked proposal - there's also the question of what a protocol like HTTP/2 means for his product.

Although HTTP/2 started from SPDY it has evolved, and in different ways e.g. see the framing comments from the thread the OP links to.

We need a better protocol for the web now, yes we could wait around longer for more discussion but where did that get us with HTTP/1.1 - I'd be quite happy if IETF had just adopted SPDY lock, stock and barrel (and no I don't work for Google)

<comment><USER10> I'm aware that he's always been skeptical, I saw his posts as my own excitement over the idea of HTTP/2.0 died on the vine from being subscribed to the WG mailing list.

There has never and will never be a point in time where we don't need "a better protocol for the web now." The issue is that canonization was unnecessary, adoption of spdy has been progressing fine without it. And HTTP/2 diverging significantly from spdy does not inspire confidence, either. Rather it just reminds of a famous xkcd [1]and again begs the question of whether trying to turn spdy into http/2 even manages to achieve any of the goals the process was setting out for.

The whole thing just seems like a big fat SNAFU.

[1] [http://xkcd.com/927/](http://xkcd.com/927/)

</comment></comment></comment><comment><USER12> There is another interesting thread about internet of things [http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/...](http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/0602.html)

"So it looks like HTTP 2 really needs (at least) two different profiles, one for web hosting/web browser users ("HTTP 2 is web scale!") and one for HTTP- as-a-substrate users. The latter should have (or more accurately should _not_ have) multiple streams and multiplexing, flow control, priorities, reprioritisation and dependencies, mandatory payload compression, most types of header compression, and many others."

[http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/...](http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/0604.html)

"First and foremost, it needs to be recognized that HTTP/2 has been designed from the start to primarily meet the needs of a very specific grouping of high volume web properties and browser implementations. There is very little evidence that ubiquitous use of the protocol is even a secondary consideration -- in fact, the "they can just keep using HTTP/1.1" mantra has been repeated quite often throughout many of the discussions here on this, usually as a way of brushing aside many of the concerns that have been raised. So be it. It's clear at this point that HTTP/2 is on a specific fixed path forward and that, for the kinds of use cases required by IoT, alternatives will need to be pursued."

<comment><USER11> Pretty sure every ecommerce site will benefit from deploying HTTP/2

(although their tendency to fill sites full of third party components may reduce some of its benefits)

<comment><USER13> Not exactly sure under what specific scenarios "every e-commerce site" will be running, but if HTTP/2 == SPDY, it's not looking good on mobile: [http://conferences.sigcomm.org/co- next/2013/program/p303.pdf](http://conferences.sigcomm.org/co- next/2013/program/p303.pdf) <== TLDR: current SPDY implementation has negative impact on Mobile performance. SPDY sucks on mobile is sort of a known fact, but this paper shows solid evidence that it's true.

<comment><USER11> The conclusion of "As a result, there is no clear performance improvement with SPDY in cellular networks, in contrast to existing studies on wired and WiFi networks." is rather different to "current SPDY implementation has negative impact on Mobile performance."

Of cousre as SPDY is only using a single connection then it's more vulnerable to issues with that connection.

<comment><USER13> So you agree that single connection is a problem :)? Under mobile, where high RTT is the norm rather than the exception, this has compound negative effect on performance (mistaken long response time as packet loss, reducing the congestion window that makes all flows suffer, etc, etc.). Everything else being equal, applying SPDY on mobile introduced this new mobile "vulnerability", isn't this SPDY's negative impact on Mobile? Sure, if cellular networks has the same delay/packet loss characteristics as wired/wifi, SPDY would fly, but mobile and wired/wifi are clearly not the same. Also, I used that paper just as an example showing SPDY's performance problem on mobile (with very nice detailed analysis why SPDY suffers). My conclusion of "SPDY sucks on mobile" is from my experience, not from that paper. I just use that paper to show my point. Actually, I think their paper's conclusion is a little bit too "polite" toward SPDY. [Edit: adding reference to the paper] In that paper the sentence right before the "conclusion" you quoted is "In cellular networks, there are fundamental interactions across protocol layers that limit the performance of both SPDY as well as HTTP."

<comment><USER11> I've tested SPDY over wired / wifi but not over mobile so my mobile experience is anecdotal.

That said all my mobile browsing (minus HTTPS) is run over SPDY (via the Google proxy) and I wouldn't describe it as sucking.

Even in the HTTP case it will still depend on what resource the packet loss etc., occurs for e.g. if it's something on the critical rendering path will it make that much difference?

<comment><USER13> Glad that you brought up the critical rendering path, because SPDY uses single connection for all requests, once a packet loss/re-transmission happens, the entire connection's congestion window will be cut, which will affect _all_ requests, so most definitely it'll hurt requests on the critical rendering path. Actually the good old HTTP1.1 doesn't suffer from this because if multiple connections are used, and only one connection suffers packet loss, only the request using that connection will suffer(assuming pipelining is not enabled), the other requests using other connections won't. This actually reduces the chance of resources on critical rendering path suffer from packet loss.

<comment><USER11> But is there any research into how often the 'independent' connections actually mitigate against packet loss?

Even on HTTP if the packet loss comes in the middle of negotiating the connection for the CSS, the page is still going to be waiting for the three seconds timeout before re-negotiating the connection.

<comment><USER13> We've seen in our work, that under high RTT, high packet loss rate (you can simulate similar effect by using things like dummynet, but it wont' be exactly what you'd expect on cellular network due to reasons mentioned in ATT lab's paper), SPDY results in performance degradation over raw HTTP. Also, I'm not saying 'independent' connections can mitigate against packet loss, it can't, and for the case you mentioned, definitely we'd get a performance hit (either first paint or pageload). It's just SPDY makes it worse than the default HTTP behavior, and that's understandable because it only uses single connection, and single connection suffers from different sorts of problem, and you seem to agree this from your first comment.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Interesting response from the WG chair: [http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/...](http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/0820.html)

An aside: I find it odd how HN users jump to agreement when a link to a single mailing-list message is posted, ignoring other discussion on the thread. I think it's because the UI makes it hard to see the rest of the conversation (unlike -say- the comments UI on HN itself)

</comment><comment><USER15> To put the comment and its author in context, Poul-Henning Kamp is the main developer of Varnish, a widely used high-performance standard-compliant HTTP cache.

PHK has experience of HTTP both from the server point of view (the main job of Varnish is acting as a fast HTTP server) and from client point of view (Varnish acts as client to the slow upstream HTTP servers).

As a side note, he also refrained for years from adding TLS support to Varnish after his review of OpenSSL and SSL in general (see [https://www.varnish- cache.org/docs/trunk/phk/ssl.html](https://www.varnish- cache.org/docs/trunk/phk/ssl.html) ).

<comment><USER16> Good one. More context on the ideas and proposal Poul-Henning has put on the table: [http://phk.freebsd.dk/words/httpbis.html](http://phk.freebsd.dk/words/httpbis.html)

</comment></comment><comment><USER17> A much better comment to link to would have the grandparent, by Greg Wilkins from Jetty, who gives a lot more substance and context to the debate: [http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/...](http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/0807.html)

It does seem a little shocking that the WG chair is proposing last call while still there's serious discussion of things like dropping HPACK.

</comment><comment><USER18> I'm here in case you want to ask me anything.

Poul-Henning

<comment><USER19> For those of us who don't follow this discussion in detail, why are you thinking the protocol needs to be scrapped outright rather than modified? Is it simply the complexity Greg Wilkins mentioned or are you really thinking about bigger philosophical changes like dropping cookies as we know them? Dropping HPACK seems like a great engineering call but that seems like a relatively minor change rather than starting over.

[http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/...](http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/0833.html) made me wonder what your standby plan would be – let the people who really need to care about performance use SPDY until a more ambitious HTTP 2.0 stabilizes? One of the concerns I have is that many people want performance now and it seems like HTTP 2.0 might turn into the next XHTML if it takes too long to emerge.

<comment><USER18> I think the fundamental problem with HTTP/2.0 is that it is a inadequate rush job for no good reason.

If you really want to gain performance for instance, the way to go is to get rid of the enormous overhead of cookies, to replace the verbose but almost content-free User-Agent header and so on.

Likewise, wrapping all the small blue 'f' icons and their associated tracking icons in TLS/SSL does not improve privacy on the net in any meaningful way.

But the entire focus has been to rush out a gold-plated version of SPDY, rather than to actually solve these "deep" problems in HTTP.

Similarly: Rather than accept that getting firewalls fixed will take a bit of time, everything gets tunneled through port 80/443, with all the interop trouble that will cause.

And instead working with the SCTP people on getting a better transport protocol than TCP ? Stick it all into the HTTP protocol.

Nobody seems to have heard the expression "Festina Lente" in this WG.

<comment><USER20> All these concerns share an overlook of the practicalities of the web.

On the protocol level, there is a huge knowledge and API momentum that makes any protocol that fundamentally differs from HTTP an uphill battle for adoption. Whatever changes are made to HTTP, if it is too different from the application POV, it will linger behind.

Same thing about tunneling. It may not be elegant, but it's the way to fight the system. You won't change IT behaviour with a protocol change. One possible way to work would be to make new version oF HTTP have a working mode that reduces overhead to a minimum for any tunneling operation.

(The same argument hold to SCTP vs TCP.)

<comment><USER18> A well designed HTTP/2.0 would _not_ "fundamentally differ from HTTP", and it would be trivial for web-servers like NGNIX and APACHE or frameworks like PHP to mask the differences for the application code.

For instance moving cookies to the server side would just require a simple key-value store lookup.

<comment><USER21> Forgive me if I'm not well enough informed to partake productively in this discussion. I just wanted to ask:

Can't anyone implementing a webclient and webservice on top of common web servers and browsers, choose to forgo cookies and keep the state server side? If this is so, then why do people choose to use cookies if they give more overhead?

Also you would need to keep some sort of unique identifier on the client, that the client can send the server, in order for the server to be able to look up the session state (a session id). Isn't this what cookies often are used for? I'm guessing this is probably what you meant "information-free session nonces" would solve above. This sounds interesting, could you explain this scheme to me or maybe point me in the direction of a good resource?

<comment><USER18> They could if the client provided a session-id so they knew which "cookie" to retrive from server-side storage.

My proposals is to do that, and have the top bit in the session-id mean "Persistent" or "Anonymous", so that client undisputably controls if anything will be stored about the session.

A Pesistent session-ID would be the same next time you visit the site, an Anonymous would be random, and thus not retrive any state on the server side, even if they saved it last time.

This would put the privacy decision in the hands of the client, provided we also eliminate crap like almost-per-user-unique user-agent headers.

<comment><USER22> Can't the client side do this already (with HTTP/1.1) by turning off cookies?

Or are you pushing for browsers to turn off cookies by default?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> I think it makes sense to take the time to get it right. Every version of HTTP will effectively have to be supported by just about every server and client forever or otherwise the web will break.

An incredible aspect of the web is that Tim Berners-Lee's first website back at CERN still works in modern browsers. Same with things like basically the entire Geocities archive.

When it gets to core infrastructure like HTTP you can't just iterate quickly and expect the entire internet to constantly upgrade along with you.

What works for early stage lean startups won't work here.

</comment><comment><USER24> What an awful way to try and get a point across. An aggressive tone and negative words baked into every other sentence, making the statements very loaded. There's probably a lot of missing context from viewing only this link, though.

</comment><comment><USER25> I think that one of the best things about HTTP/1.0 (and to a lesser extent 1.1) is its simplicity. The reason, to me, that that simplicity is so vital is because it has fostered large amounts of innovation.

</comment><comment><USER26> It should be noted that the sender of this e-mail is Poul-Henning Kamp, known among other things for another e-mail from back in the day (relatively speaking): [http://bikeshed.com/](http://bikeshed.com/)

</comment><comment><USER27> I haven't been following the development of HTTP/2.0. What are the most egregious "warts and mistakes" in SPDY?

<comment><USER13> Mobile is one of them, although OP's arguments are valid as well. ([http://conferences.sigcomm.org/co- next/2013/program/p303.pdf](http://conferences.sigcomm.org/co- next/2013/program/p303.pdf)) Also, among many other things: every thing over SSL. Single Connection. Also, less of a technical problem, but as many already mentioned, too complicated as compared to plain text human readable HTTP 1.x

<comment><USER28> also ssl everywhere without authentication by default. ie slower, encrypted, but not actually safe.

</comment></comment></comment><comment><USER29> Would it be accurate to suggest that the rushing of Google's SPDY, as HTTP/2.0, through IETF standardisation is roughly equivalent to the situation a few years ago when Microsoft pushed Office Open XML through as an ECMA standard? Or is that just a huge mischaracterisation?

<comment><USER30> That's a huge mischaracterization.

There are a few different implementations of SPDY, and a clear use case where it applies. Also, it's a clear standard, made for being used.

What's happening here is that there is a group of very active people that create most of the software we use on the web, and have a use case they want to support. At the same time, there are lots and lots of people that are not as active, with a huge amount of use cases that will be hindered, but since they are not active, they have very little voice.

<comment><USER29> Thanks for the explanation, I haven't been following the progress of SPDY so I'm not familiar with the detail. What use cases would be hindered by this new standard?

<comment><USER30> There are people complaining that it will break things because it's binary, that they can't have mandatory encryption, and that it's just too complex to fit in limited resources. There are probably other complaints that I didn't see.

I've never read it in enough depth to verify those claims, but the response from the standard group is always "then use HTTP 1.1", what is as a non- solution as it gets.

SPDY was great exactly because it was not the standard, it was an extra option, available if everybody agreed to it. Call it HTTP 2, and it will become mandatory in no time. IETF calling it optional won't change a thing.

</comment></comment></comment></comment><comment><USER31> I'm in favor of dumping HTTP/S and using a faster and more secure (by default) Transport protocol altogether. Post Snowden revelations we should be focusing our energy on that, rather than continuing to hack around this old protocol to make it faster and more secure.

<comment><USER32> MinimaLT [1] comes to mind. Minimal latency through better security sounds very appealing, especially when it's not a marketint trick but a paper signed by people like DJB.

The way I see it though, is not only to have a protocol, but how to get adoption. Especially when you're talking about network protocols, you need rock solid stacks in all major operating systems which is not an easy feat to accomplish.

[1]: [http://cr.yp.to/tcpip/minimalt-20130522.pdf](http://cr.yp.to/tcpip/minimalt-20130522.pdf)

</comment></comment><comment><USER33> Well, SPDY might be a "prototype", but it's solving real problems _today_ \- I care less if it's perfect or not, if it solves _all problems_ or not, as long as it's easy to implement, has a decent footprint, and offers significant improvements over HTTP/1.1. An imperfect working prototype is better than a perfect blueprint that materializes in distant future where problems and environment can differ greatly.

<comment><USER34> Well, according to this mail from the Jetty-team, it doesn't seem like http/2.0 is easy to implement at all: [http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/...](http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/0807.html)

Furthermore, if http/3.0 is already being discussed, why not just skip http/2.0 entirely, and live with the current http/1.1+SPDY situation until the work towards a new standard for http is actually done?

<comment><USER35> What does "LC" mean in that post?

<comment><USER36> "Last Call".

See [http://datatracker.ietf.org/doc/help/state/draft- iesg/](http://datatracker.ietf.org/doc/help/state/draft-iesg/)

</comment></comment></comment></comment><comment><USER37> It's not perfect so start over. Seems like the definition of why v2 is always so hard.

</comment><comment><USER38> Sounds to me like the real problem is lack of IP addresses, and the best strategy would be to hold off on updating HTTP and work on IPv6 ubiquity first. I can see why Google went a different route, but we don't all have to follow.

</comment><comment><USER7> Just like they admitted that XHTML 2 was a mistake and scraped it, I feel they should do the same with this nonsense.

Nothing about spdy or http2.0 sparks any sort of confidence with regard to proper robust protocol design, keeping things simple nor properly separating concerns.

<comment><USER39> It's funny that you mention XHTML 2, because I think it demonstrates the opposite of what you are arguing.

XHTML 2 is a lot more like what PHK is proposing: an attempt to "rethink" HTML, come up with something simpler, revolutionary rather than evolutionary, "The Right Thing." It was an attempt to reinvent the space from first principles, and had lots of ideas that were theoretically good but unproven at large scale.

When that went nowhere, the world settled on HTML5: evolutionary, incremental, and based on standardizing existing practice. Much less sexy, but more useful in practice.

There is a time and a place for bold new ideas, but a standards body designing v2 of a protocol isn't it. Standards are for codifying proven ideas. When standards bodies try to innovate you end up with XHTML, VRML, P3P, SPARQL, etc.

</comment></comment><comment><USER40> You know what we need, we need to pick _one_ of those people and give 'em _one_ day to invent HTTP/2.0 and it'll be a better spec compared to letting them all "decide" together by nerd-fighting each other into eternity.

No standard is perfect, but the worst standard is no standard.

Make up your fucking mind already.</comment>


Is Big Data turning government into 'Big Brother'? - <AUTHOR> http://www.stowsentry.com/ap%20financial/2013/06/07/is-big-data-turning-government-into-big-brother-1370623515

<comment><USER2> They always were, it's just easier now.

</comment><comment><USER3> where have you been? It's been Orwell for real for a number of years now.

</comment><comment><USER4> "Big Data"

I prefer my data medium rare, please.</comment>


Gmail's upcoming redesign focuses on work chat, rolling out later this year - <AUTHOR> https://www.androidauthority.com/google-gmail-redesign-work-chat-1138200/ <comment><USER2> I really do hope that some of the user testing they do includes folks with ADHD.</comment>


nukapi – the reliable cloud database with dead simple pricing - <AUTHOR> https://www.nukapi.com/products/ <comment><USER2> Can you help me. Why wouldn't I just setup Postgres or a similar database on a less expensive and better known cloud provider (Digital Ocean, AlibabaCloud, Amazon, Azure, Google etc.)? Many of these have similar pre-configured database systems.

<comment><AUTHOR> Hi, thanks for the question! Of course you can do that. Our offer is for people who want to get started fast without losing focus. Maintaining a database is a standard task that you could do yourself. But getting it right might consume some time, you probably want to invest in your application. You need to consider backups, possibly a failover solution, monitoring and a scaling strategy. If maintaining a database is the core of your business, go ahead. If you want to get started fast, maybe you give nukapi a shot.</comment></comment>


Windows 8 Tablet OS Is Just Windows 7 With a New Skin - <AUTHOR> http://www.wired.com/gadgetlab/2011/06/windows-8-tablet-os-is-just-windows-7-with-a-new-skin/

<comment><USER2> Just like WP7, it's only beautiful skin-deep.</comment>


NYPD video warning about leaks to the media is leaked to the media - <AUTHOR> https://www.nydailynews.com/new-york/nyc-crime/ny-nypd-video-warning-leaks-leaked-20200225-ds5kqdjlwrh3bdtmgpwffmprhi-story.html <comment><USER2> > Unfortunately, our website is currently unavailable in most European > countries. We are engaged on the issue and committed to looking at options > that support our full range of digital offerings to the EU market. We > continue to identify technical compliance solutions that will provide all > readers with our award-winning journalism.</comment>


A year ago, I typed suicide in Periscope and hit stream – Screening mental illness - <AUTHOR> https://neuroamer.wordpress.com/2016/08/08/a-year-ago-i-typed-suicide-into-periscope-and-hit-stream-why-arent-we-using-social-media-to-screen-for-mental-illness-and-offer-access-to-care/ <comment><AUTHOR> Thoughts on this or links related to this subject appreciated--still working out my own thoughts on the subject.

</comment><comment><USER2> I am mentally ill to the point that I am disabled.

Many sites I have been on had bullies telling me to kill myself when they figure out I am mentally ill.

There is no way to screen for memtal illnesses on the Internet not all are detected like mine.

When people and companies think of disabilities they imagine someone in a wheelchair, blind, deaf, ect not someone with a mental illness.</comment>


Estimated car cost as a predictor of driver yielding behaviors for pedestrians - <AUTHOR> https://www.sciencedirect.com/science/article/pii/S2214140520300359. <comment><USER2> I looked over the study to determine if there was a criteria for "yield" vs "non-yielding".

I _think_ based on the study write-up under section "2.2. Pedestrian crossing", that yielding was based on:

\- car in nearest lane is 200 yards away

\- pedestrian placed one foot into crosswalk

\- pedestrian attempted to make eye contact with driver

\- driver reduces speed -> threshold for "safe to attempt"

\- driver yields or does not -> fits criteria for "yields"

It isn't clear if they considered a failure by the driver to invigilate the entire crossing as a "failure to yield"; e.g. in my district, if a pedestrian is present in the cross walk at any part of the road, I cannot proceed full- stop, and that would be a "failure to yield" under my road laws act.

After thinking about this study, and attempting to not make myself look like a fool if my original issue was addressed, I noted a few more deficiencies in this study:

\- road structure (other than mid-block crossing, and 35MPH; e.g. number of houses, other entry ways, number of business, two lanes or four lanes; traffic calming measures)

\- road use (isolated neighborhood collector; retail zone; between two high- congestion areas; etc)

\- volume of crossings by non-study participants

\- recency of the crossing

\- existing use of the crossing (inter-neighborhood? inter-shopping centre? school to park?)

\- driver _perceived_ age of pedestrians and pedestrian capability (infirm, underage, active)

This all leads into:

\- driver awareness of existing pedestrian crossing

\- driver familiarity with pedestrians at that crossing

\- driver intention with the road

\- brand new and underused crossing? old crossing with very low non-study volume?

\- is 4x30 = 120 crossings at road 1 and road 2 high or low for that area?

I don't feel this study is useful in isolation, and I'd be irritated if someone used it as a basis for point-making.

</comment><comment><USER3> > Of 461 cars, 27.98% yielded to pedestrians.

This is... pretty bad!

</comment><comment><USER4> How do you estimate the cost of a car that you observe on the street? If someone drives a seven year old car that cost a lot new, how do you know if they bought it new or for a fraction of the price?

<comment><USER5> If you knew the cost of the car you wouldn't need to estimate it.

<comment><USER4> If it's uncorrelated to known characteristics, then arbitrarily choosing a number isn't really "estimating".

<comment><USER5> Good thing it is correlated to the characteristics in question.

<comment><USER4> Assuming it was just purchased. Which is my point. The average car was not just purchased, I feel confident in saying.

<comment><USER5> You don't have a point. A correlation doesn't have to apply for every single instance, not even for the majority.

<comment><USER4> My original post contained the suspicion that nobody was estimating _cost_. Although I never clicked the link, someone else ("def8cefe") posted as a response to me, that they _indeed_ did not use cost but current value.

So, despite being downvoted, I think I made a substantive contribution in identifying the headline as misleading. This in turn would affect how a reasonable person interprets the meaning of the whole thing.

What is _your_ point?

<comment><USER5> Cost correlates with current value.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> >Estimated car cost as a predictor of driver yielding behaviors for pedestrians

Why not: > Correlation of vehicle price to the probability its driver yields to a pedestrian.

Still improve-able but "driver yielding behaviors" is too mafan.

Interesting work, But to be nit picky, the title is typical academese. I.e less readable than it needs to be even after taking the higher need of precise and accurate language.

Maybe:

Correlation of a driver yielding to a pedestrian with the vehicle price?</comment>


Ask HN: How come my Ryzen 3750H is faster than my RTX 2060 in TensorFlow? - s-p-n I thought the RTX would do better here, but the Ryzen 3750h performs better on training a model in tensorflow. I'm using this guide to get things going, and I'm usng tf-nightly with Ubuntu 20.04.
https://www.tensorflow.org/tutorials/quickstart/beginner
I'm wondering if using nvidia 440 drivers is the reason? I also have 3 versions of CUDA installed (10.0, 10.1, and 10.2). The tensorflow-js test I did uses CUDA 10.0, and the Ryzen performs roughly 50% faster. The Python test I did uses CUDA 10.1, and the CPU is less than 10% faster.
Even so, shouldn't the GPU perform an order of magnitude better here? I feel like I must be doing something wrong :/ <comment><AUTHOR> The network that you train in that tutorial is quite small. Your networks have to get quite large before the overhead of transferring the network onto the GPU is negligible to the cost of training it. You'll see the benefit of the GPU with larger models.

</comment><comment><USER2> I think my calculations are correct here

      Model       Zen+  2060
      Cores       4     1920
      Threads     8     1920
      Cycles      2.3   1.365
      FP64 GFLOPS 2944  163
      FP32 GFLOPS 5888  5242
      FP16 GFLOPS 11776 10483

So it would kind of make sense yeah. 2060 isn't that strong.

But note: I'm not totally sure on the Zen+ theoretical speeds

<comment> s-p-n Yeah, I just finished installing the CUDA/tensorflow/python set on windows 10, and have the exact same results. So, it's not my configuration that's the problem.

Wow, this really brings to light how well Ryzen really performs. My nvidia 950m put shame to whatever intel i7 I had on my last laptop lol. Now I'm not even sure why I got a GPU on this rig

<comment><USER2> Kinda shows how gimped gaming GPUs are for doing training really.

</comment></comment></comment><comment><USER3> Didn't know that TensorFlow works on AMD GPUs..

<comment><USER4> CPUs</comment></comment>


Show HN: Invite friends to SSH into your laptop using their GitHub handle - <AUTHOR> http://gravitational.com/blog/instant-ssh-github/ <comment><USER2> Neat.

I use the following incantation when authorizing folks to ssh into my servers via github public keys:

        curl https://github.com/[github name].keys >> ~/.ssh/authorized_keys

[github name] here should be replaced with github username of your friend or colleague. Really handy because I can just authorize them without a human request/response loop and manual key moving. Simple and no external tools needed. Normal caveats about authorizing people apply.

<comment><USER3> This is really the correct way to accomplish what this project is trying to do. No central proxy server that you need to trust and can be trivially done with the commands you already have installed.

I would honestly highly recommend _against_ using Teleconsole for those reasons.

<comment> old-gregg No it is not. Connecting two machines behind two different NAT'ed networks requires a proxy of some kind, and there's nothing you already "have installed" that would help you.

Teleconsole is an instant VPN+SSH in one command and it would be wise to educate yourself on what it does (reading just the 1st sentence of the blog post would be a good start) before recommending anything.

</comment></comment></comment><comment><AUTHOR> Hey HN - This is basically a hosted version of Teleport[0], which may scare some people. We don't store the sessions and you can always self-host if you prefer.

[0] [http://gravitational.com/teleport/](http://gravitational.com/teleport/)

<comment><USER4> > We don't store the sessions

Interesting - but how can we trust you?

<comment><USER5> If you don't, just self host!

<comment><USER6> What if I don't trust myself?

<comment><USER7> HN can't help with that (yet) :)

</comment></comment></comment></comment></comment><comment><USER8> Would be neat if having done

        teleconsole -i other_users_github_id

my teleconsole session ID would be sent to server along with _my_ Github ID (optionally other user's too) so that they could

        teleconsole -j my_github_id

to join instead of having to share session ID and fumble around with that.

No more/less secure that I can see, but it would be more convenient.

<comment><USER9> would be nice, but it would likely introduce some additional complexity for instances where there might be more than one live session spawned by a user.

<comment><USER8> > _additional complexity for instances where there might be more than one live > session spawned by a user_

I'm trying to imagine the situation that makes that worth supporting?

That's not going to be a development server used by an entire team, for example, because whose Github credentials would be on it?

Even so, it could just give a list of session IDs in such a case, and ask which of 1/2/3\. The additional complexity is only that the lookup value is a list of strings instead of a single one, surely?

<comment><USER10> In my head, having to have the session id is almost a good "two factor" if you will.

<comment><USER8> I suppose. Having someone's private key _and_ knowing who's offering the legitimate owner of that key a secure session at that point in time is already a tall order though!

</comment></comment></comment></comment></comment><comment><USER11> I prefer using tmux for this to be a bit more secure. I wrote a blog post about this [0] since it is a bit of a pain in the ass to set up properly. Maybe you should explore this too for your product.

[0] [http://joy.pm/2015/07/11/pairing_over_tmux.html](http://joy.pm/2015/07/11/pairing_over_tmux.html)

<comment><USER12> Nice writeup, thanks for sharing.

</comment></comment><comment><USER13> I suppose this is useful if you have two systems both behind NAT...

I've run into many situations where I'm remote and need to SSH into a NATed machine to fix something, and I typically will SSH reverse tunnel to a VPS.

From the NATed machine:

        ssh -fN -R52222:localhost:22 user@publichost

And then from the public machine:

        ssh user@localhost -p 52222

</comment><comment><USER14> I'm confused and have a couple questions:

1\. Why would I want someone to ssh into my machine -- at least with the frequency that a service to help me do it is valuable?

2\. How is this easier/better than saying 'hey bro whats your ssh pub id? -- eh.. do `cat ~/.ssh/id_rsa.pub`

Over all this seems like a tool that only super technical people would ever use, and for those people adding a key to authorized keys is trivial.

<comment><USER15> Yeah, "just share the Teleconsole ID" seems like an identical step to "just share the public key".

<comment><USER9> "just share the public key" doesn't solve firewall, nat, etc network issues that might be a barrier. If you went that route, you'd likely want something like ngrok too.

</comment></comment></comment><comment><USER16> Regarding remote pair programming I haven't found a better or faster solution than TMate ([https://tmate.io/](https://tmate.io/))

If I am feeling paranoid about the user on the other side, I only share just the read-only link, or the web link.

<comment><USER17> This is pretty cool. Multiplayer terminal sessions.

</comment></comment><comment><USER18> I don't have friends that know what SSH is. Just wonderful colleagues.

<comment><USER19> I know the feeling...

</comment></comment><comment><USER20> > ssh-import-I'd gh:my-gh-name

That little command will pull down your GitHub public keys and add them to authorized key file for the user who runs it. Great for setting up new computers. I run it on boot-time for imbedded devices so that I can always access them.

<comment><USER21> That's cool, but it seems like a lot of code to do something that:

\- You can do in one line of bash: curl [https://github.com/user.keys](https://github.com/user.keys) >> ~/.ssh/authorized_keys \- The bash one-liner is transparent and educational: it tells you clearly and intuitively where the keys are coming from and where they're going, educating users about the existence of the Github/Gitlab- published keys and about how the authorized_keys file works

You seem to require a lot of code, and lose a lot of very real advantages, for the sake of a bit of brevity. What are the other advantages of this tool?

<comment><USER22> Executing the curl command with no error checking and blindly appending it to your ~/.ssh/authorized_keys could easily bork the latter. Wrapping it in a fancy command allows for error checking and response validation. Otherwise you could end up the source of [https://github.com/503.html](https://github.com/503.html) in there!

<comment><USER21> Perhaps, but the simplicity of the curl command provides enough insight into exactly what it does to understand what precisely it does and what could go wrong. I can see what file it's writing to, I can check that file, I can be pretty sure it's not doing anything else weird behind the scenes.

<comment><USER22> That's the whole point. You have to manually do those things. It's not that you _can 't_ do them, it's that if you tell someone " _Just run curl ... >> ..._" without the validation part they can get hosed. Even in a script you need to be careful about it because a non-200 HTTP response still gives a zero (i.e. success) exit status.

</comment></comment></comment></comment></comment><comment><USER23> What kind of abuse prevention measures does this have in place? As it stands it looks like a super convenient way to scp garbage into other people's computers and I'm not sure I'm sold on that.

<comment><USER24> You argument is biased and non-factual. Default ssh measures keep un-trusted entities from gaining access, normally. Conversely, once access is granted by the admin to trusted entities, the normal UNIX permissions continue to provide means by which access to the file system is limited by user permissions. Thus, simply by an admin granting access to a system, your (hypothetical) arguments become false and pointless to discuss.

<comment><USER23> You must be kidding me. My "argument " is a _question_. My "hypotetical arguments" consist of me _asking_ if there is some thing stopping people from scp'ing things to my computer _then running them_.

You talk like phishing and privilege escalation weren't things that exist. Have you _ever_ managed any public-facing service of any importance?

<comment><USER24> Actually, those types of questions are called _leading questions_. Making a point based on a hypothetical can not be logically used to make a factual point without it being a bias, even if you phrase it as an "unknown", or question. Your last comment here shows your tendency to blame and use biases for making arguments, which is unfortunate given you appear to be asserting authority on matters of "public facing" servers. You know what they say about making assumptions.

I would note that using biased arguments is an inefficient process in most cases. It's akin to recursion of a process which, in my experience, has brought many a more server to its knees than a hypothetical threat from double authorized access (hash + key).

<comment><USER23> What a bad troll. Try something more subtle next time.

</comment></comment></comment></comment></comment><comment><USER25> Another way, using only software that you have already: get your friends' public keys and make a burner account on any jointly-reachable server/laptop/whatever and do a follow-the-leader screen:

[http://blog.endpoint.com/2009/09/gnu-screen-follow- leader.ht...](http://blog.endpoint.com/2009/09/gnu-screen-follow-leader.html)

</comment><comment><USER26> Hmm. Seems like all traffic goes through a central proxy server.

Shouldn't it be possible to use the central server only for hole-punching and implement a TCP-over-UDP connection so that the clients can directly communicate with each other? (And don't the major browser vendors already have public NAT-hole-punchers for WebRTC?)

<comment><USER27> _" Hmm. Seems like all traffic goes through a central proxy server."_

My first thought.

Also, the server and code may be secure, the weakest point is a person. cf: _" You can share the Session URL with a colleague in your organization. Assuming that your colleague has access to teleport.example.com proxy, she will be able to join and help you troubleshoot the problem on "db" in her browser."_ ~ [http://gravitational.com/teleport/docs/quickstart/](http://gravitational.com/teleport/docs/quickstart/)

</comment></comment><comment><USER28> how is

"curl [https://www.teleconsole.com/get.sh](https://www.teleconsole.com/get.sh) | sh "

Still considered even a remotely acceptable method for installation?

<comment><USER29> What's wrong with it?

If you're claiming that you don't get the ability to audit the code, I'd like to watch you audit a ./configure shell script generated by GNU autoconf.

If you're claiming that you want to apt-get install so the package maintainer has audited the code, I'd like to watch _them_ audit the ./configure shell script.

Downloading and auditing code from an untrusted source is security theatre. Don't install it at all, if you don't trust it. Or use some platform (the web, iOS, Android, Qubes, etc.) that makes it such that there's no need to audit it because the app is restricted in what it can do.

<comment><USER30> if the connection closes mid stream it could potentially run something catastrophic (rm -rf /) as sh will execute the partial command in its buffer.

<comment><USER29> Yes. Wrap the entire script in a function and call the function at the end once the whole thing has transferred. [https://install.sandstorm.io/](https://install.sandstorm.io/) , for instance, does this.

</comment></comment></comment></comment><comment><USER31> You can use SSH keys for VNC, too. Would be neat to see a PoC that allowed you to invite someone to remote control your computer temporarily via their github handle. [https://ubuntuforums.org/showthread.php?t=383053](https://ubuntuforums.org/showthread.php?t=383053)

</comment><comment><USER32> Other than using [tmate]([https://tmate.io/](https://tmate.io/)), I use some aliases:

github-pair ([https://github.com/chilicuil/shundle- plugins/blob/master/ali...](https://github.com/chilicuil/shundle- plugins/blob/master/aliazator/aliases/extra/curl.aliases#L4))

github-unpair ([https://github.com/chilicuil/shundle- plugins/blob/master/ali...](https://github.com/chilicuil/shundle- plugins/blob/master/aliazator/aliases/extra/curl.aliases#L5))

Those add / remove keys from github to ~/.ssh/authorized_keys

</comment><comment><USER33> Are there any advantages to using this instead of exposing port 22 temporarily via ngrok advantages adding your friend public key to authorized_keys? (Which has the added advantage of being pure, unmodified SSH)

[https://ngrok.com](https://ngrok.com)

<comment> vhost- I don't like using the TCP functionality of ngrok because it seems to always use the same hostname (0.tcp.ngrok.io) with a random port. So anyone can just scan for open ports on that domain and start trying to connect to things. The HTTP forwarding at least gives you a random subdomain.

</comment></comment><comment><USER34> Note to the author: Please don't have a command line flag that either means ( a valid local posix path ) or ( a username/handle from a specific online service that will be fetched over the network ). *nix cli tools are supposed to be unambiguous. I'd fork/issue/patch it, but I don't have a need to let people ssh into my any of my boxes. Just posting this here because its a valid learning opportunity that making something "easy" is not always the right choice in a cli tool, and that namespaces are important. What if I have a file named the same as a github user? Which thing will work? Will that behavior change unexpectedly? Best to make them different flags.

<comment><USER35> I now regret that my github username isn't: ".authorized_keys".

</comment></comment><comment><USER36> Publishing the public key that you use to push to github/gitlab is not a big issue... But Re-using your github key-pair, to connect to other unknown and uncontrolled places, _is_ a security issue.

Even re-using your daily system user, for this, is a security issue.

But if you never did read the sshd_config man page, or never did play with its options, maybe you're unaware of this.

Also the sshd could be modified at source level.

<comment><USER37> Can you explain how this could be exploited (assuming that the user does not ignore warnings)?

<comment><USER35> I'm not sure if it is a big issue without passing in -A to allow forwarding of authentication to a second server beyond the one you're logging in to. In theory you should still be in control of your secret key and the session even if the first server attempts to proxy or steal your private key. Note that your console/tty or shell might be vulnerable to a malicious server in any case.

Stuff like:

[https://m.theregister.co.uk/2016/01/14/openssh_is_wide_open_...](https://m.theregister.co.uk/2016/01/14/openssh_is_wide_open_to_key_theft_thanks_to_roaming_flaw/)

seem to indicate that a patched ssh client should (no longer) leak private keys without the -A parameter...

</comment></comment></comment><comment><USER38> I'm guessing the SSH session between me and my friend is not encrypted end-to- end because of proxies and what not in between?

<comment> old-gregg It is properly encrypted:

Your machine, being an SSH server, gets to decide who can login. The encryption works just with any normal SSH session: between the end user and the server (your machine).

The cloud bridge running on [https://teleconsole.com](https://teleconsole.com) simply acts as a proxy connecting sockets between two users who are behind NAT (without being able to decrypt).

Disclaimer: I'm the author of Teleconsole. [edit: formatting]

<comment><USER39> Does it run as a proxy or does it just do the nat hole punching?

<comment> old-gregg This page is good: [http://gravitational.com/teleport/docs/architecture/](http://gravitational.com/teleport/docs/architecture/)

The proxy accepts two incoming connections: from your server and from the client, then it bridges them and allows the client to negotiate an SSH handshake with the server.

</comment></comment></comment></comment><comment><USER40> This feature was implemented in tweemux, a lighter wemux-like tool.

[https://github.com/PeopleAdmin/tweemux](https://github.com/PeopleAdmin/tweemux)

It's pretty neat.

</comment><comment><USER41> If you only want to share your shell and not allow anyone to send commands, use [https://shellshare.net/](https://shellshare.net/).

</comment><comment><USER42> Awesome! I just launched a DevOps consulting company ([https://elasticbyte.net](https://elasticbyte.net)), and Teleconsole looks like a great option for interactive SSH sessions with clients.

</comment><comment><USER43> I would be curious to hear anyones feedback on their experience running Teleport in production. I like what I have read on the site and it certainly has some nice features.

</comment><comment><USER44> So how does the -i parameter know to look in a local file or on github for the public key? Does it look for a ".pub" in the filename? Feels clunky to me.

<comment><USER45> No. I was curious about that too, they check if the parameter is a file and if it's not they try and fetch the github user's keys. [0]

[0] - [https://github.com/gravitational/teleconsole/blob/master/lib...](https://github.com/gravitational/teleconsole/blob/master/lib/identity.go#L134)

</comment></comment><comment><USER46> Reminds me of tmate

<comment><USER47> Same, here. tmate.io is pretty handy in such cases.

</comment></comment><comment><USER48> Yeah, what a great idea, let random "cloud" services authenticate who gets to login to your machine!

<comment><USER49> Being unconstructively snarky about a concept that another member of this forum has presented is both poor manners and defies the guidelines linked in the bottom of the page

<comment><USER48> Just making a critique of the concept. Didn't think that was against any guidelines.

<comment><USER50> If you're going to start your sentence by the heavily condescending "Yeah, what a great idea", then don't pretend you don't understand how that could be against the rules. You can't have your lunch and eat it. Especially if you're not going to provide some facts / hard evidence to back up your assertion that this is, in fact, not a good idea.

<comment><USER48> I think the rest of my statement backed that up pretty well.

I'm not clear though - I'm to expect hackernews has rules which demand I weasel-word my criticisms? That seems ridiculous.

<comment><USER51> The Hacker News community expects civil and substantive comments, as others have already pointed out. Reading this as demanding weasel words is disingenuous.

<comment><USER48> Well then, clearly the definition of "civil" varies from person to person.</comment></comment></comment></comment></comment></comment></comment>


The psychology of why we're irrationally more scared of terrorism than guns - <AUTHOR> https://qz.com/898207/the-psychology-of-why-americans-are-more-scared-of-terrorism-than-guns-though-guns-are-3210-times-likelier-to-kill-them/ <comment><USER2> > jihadists killed 94 people inside the United States between 2005 and 2015. > During that same time period, 301,797 people in the US were shot dead

> Americans are more afraid of terrorism than they are of guns, despite the > fact that guns are 3,210 times more likely to kill them

Er, that's not really how probability works. Sure, it makes some sense but as was pointed out, most of those people shot themselves. Since I don't intend on shooting myself, the probability of me being shot is immediately a fraction of the number quoted in the article.

I'm not afraid of guns because I have the privilege of living in a safe area. I'm a lot more scared of the immediate threats to my well-being, which seem to be distracted drivers [0] and slipping on ice [1].

Admittedly I closed the article after this butchering of statistics, so I don't know if the rest of the article is as misguided.

[0] - There have been several instances where I walked out into a crosswalk but stopped because I could see a car approaching but not slowing down, with the driver staring at their lap.

[1] - I live in Ohio. It snows a lot, but people don't shovel their sidewalks. People walk on the snow and compress it into ice (combined with freezing temps at night) which can persist for a week.

EDIT: Stats folk: is there a term for this? It seems similar to a Bayesian Fallacy but I'm not sure that's exactly correct...

<comment><USER3> Actually, suicide stats indicate that "I do not intend to kill myself" is not how it works. In general, suicidal episodes seem to be short and having access to means to kill yourself increases the chance you'll actually do that. Not having the means available increases the survival rate - even small barriers like selling painkillers in smaller boxes show significant reduction in suicide rates. Another considerable factor are accidents - nobody intends to kill himself in a gun accident either, it just happens. So I think it's quite correct to include those numbers in the risk profile.

<comment><USER4> > In general, suicidal episodes seem to be short and having access to means to > kill yourself increases the chance you'll actually do that.

Well, in the moment you still do mean to kill yourself.

<comment><USER5> Is someone killing themselves something that should be included in what people fear? This seems like it might be another issue that can't be easily compared to the fear of terrorism.

</comment></comment></comment></comment><comment><USER6> A great example how, based on your readings of the data, you can lie or present any case with statistics...

First of all, among the gun deaths there are people that shot themselves, and also people shot in gang shootings and such (where, if you're not in a gang you're not that affected). So the number is somewhat inflated (of course still bigger than terrorism).

Second, people fear going into violent neighborhoods with gun crime (say Compton at night), a hell of a lot than they fear terrorism. They might agree when asked in polls that "terrorism is a great threat", but they sure as hell as pragmatically more concerned with areas with violent crime, and avoiding them in their day to day lives.

Third, as people in certain places have witnessed, terrorism can be a constant source of death and horror, with multiple incidents per year, or even daily if a country goes sour. Just because it hasn't happened in some place, it doesn't mean it's impossible to happen (e.g. if there's a sizable militant islam population in the US).

Fourth, terrorism can also bring much more horrible outcomes than the regular gun death, even more than a mass shooting. Some crazies can kill literally tens of thousands via some (not that elaborate) plan. And while it might not always be possible to predict or prevent such a thing, one can still fear it (and fear to further stir the conditions that might make it happen).

Fifth, do the people that are OK with guns believe that if there was strict gun control gun related crime would go down? Or do they believe that criminals will be the only ones with access to guns (bought illegally of course)? If the latter's the case, then it makes sense to be OK with guns, as they see them as something they can use to protect themselves against violent crime and that the criminals will have anyway. And of course nobody realistically believes that they'll snap and kill their spouse with that gun (or vise versa -- as it often happens). It's more realistic, in that sense, to fear terrorism than yourself.

<comment><USER7> I think you're wrong about point 4. Could you outline such a plan?

As a counter-example: CIA trained operatives with decades of experience and a 20+ person team launching a coordinated attack could only kill 3,000 -- and that was only because of underlying weaknesses in our security policy. The 9/11 attacks were so easy to counter, they didn't even work through one full morning. (By which I mean, 25% of the planes were downed before reaching their targets.) Reinforced cockpit doors and changes in passenger/crew behavior means that a repeated attempt likely would result in 0 deaths.

<comment><USER6> > _I think you 're wrong about point 4. Could you outline such a plan? As a > counter-example: CIA trained operatives with decades of experience and a 20+ > person team launching a coordinated attack could only kill 3,000 -- and that > was only because of underlying weaknesses in our security policy._

The attack you mention was mostly meant to be symbolic and grandiose: not to do the most damage numbers-wise.

From bombing a stadium full of people, to gas poisoning the subway, to bringing some deathly strains of a virus (e.g. Ebola etc) to some mass event, the possibilities are endless.

You don't even need to go on atomic bombs and stuff...

<comment><USER8> In the one example we have of it, a Sarin gas attack on the Tokyo subway at rush hour killed 12 people and seriously injured 50 more.

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

Guns and bombs are actually far more effective. Skimming the list of terrorist attacks in 2016, the most deadly seem to be bombs and teams of gunmen (mostly in Pakistan, Afghanistan, Iraq, Somalia, and Nigeria).

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

<comment><USER6> > _In the one example we have of it, a Sarin gas attack on the Tokyo subway at > rush hour killed 12 people and seriously injured 50 more._

It also says that it caused "temporary vision problems for nearly 5,000 others" and that "hospitals saw 5,510 patients, seventeen of whom were deemed critical, thirty-seven severe and 984 moderately ill with vision problems".

So this says more about the particular gas used or venue chosen, than about the effectiveness of such an attack to reach thousands. A different gas could have had more devastating effects, and same for a different setting (e.g. a closed stadium).

</comment></comment></comment></comment></comment><comment><USER9> It's funny I was talking to a friend and she said she's terified when driving through france because of the terrorists. So she drives non stop till she is in spain. And she is so sad about it since she loves france and can't go there anymore.

It seemed so out of the world to me, since it never occured to me that I will be the victim of a terrorist attack. And even if: what happens happens. No reason to stop going on with your life.

I have to say the only news I read are tech news. The rest I get from colleagues at lunch. And sometimes I skim through the newspaper and read some articles that really interest me.

</comment><comment><USER10> Being scared of guns is irrational. Being scared of _some_ people with guns is rational. Being scared of terrorism makes about as much sense as being scared of dying from a lightning strike. It could happen, but it's so unlikely there just isn't much point spending any time thinking about it.

</comment><comment><USER11> > (between 2005 and 2015) 301,797 people in the US were shot dead

Somewhat misleading, given that most of them shot themselves.

<comment><USER12> Yeah I would be very interested in seeing what the statistics are without counting suicides as being "shot dead".

<comment><USER13> From the CDC, .326 * 33,599 or about 10,953 firearm homicide deaths in 2014:

      Firearm—In 2014, 33,599 persons died from firearm injuries
      in the United States (Tables 18 and 19), accounting for
      16.8% of all injury deaths in that year. The age-adjusted
      death rate from firearm injuries (all intents) did not
      change significantly in 2014 from 2013. The two major
      component causes of firearm injury deaths in 2014 were
      suicide (63.5%) and homicide (32.6%). The age-adjusted
      death rate for firearm homicide decreased 2.8%,
      from 3.6 in 2013 to 3.5 in 2014. The rate for firearm
      suicide did not change.

[https://www.cdc.gov/nchs/data/nvsr/nvsr65/nvsr65_04.pdf](https://www.cdc.gov/nchs/data/nvsr/nvsr65/nvsr65_04.pdf)

You should understand that _firearm-related injuries_ will be proportionately worse. Moreover, toddlers kill people at the rate of about 1 per week which is significantly greater than terrorism deaths except for 2001 (2908 with 9/11) and 1995 (171 with Oklahoma City).

[https://www.washingtonpost.com/news/wonk/wp/2015/10/14/peopl...](https://www.washingtonpost.com/news/wonk/wp/2015/10/14/people- are-getting-shot-by-toddlers-on-a-weekly-basis-this-year/)

</comment></comment></comment><comment><USER14> As a EU citizen living where guns are essentially banned (in 30yrs I've seen a gun only once - excluding law enforcement) I'm equally scared by both guns and terrorism. Just to outline that the feeling mentioned in the title can be different given your background and social environment.

<comment><USER15> yeah, agree with you

I am from Canada and I am more scared by guns than by terrorism even given that just several days ago, we had one such attack on our soil.

A terrorist attack for me is like a lightning strike. Seems to be deadly but not very probable.

Meanwhile, living among people who casually own guns (like in US) is like living in a place where everybody has untamed wild tigers and bears at home. Unpredictable, dangerous, not very smart. It's a real day-to-day threat to our lives.

</comment></comment><comment><USER16> Journalists really need some guidelines on how to report on statistics without veering into nonsense.

</comment><comment><USER17> Who do they pick when they conduct these surveys? I don't live my life any differently regardless of the relative threat of terrorism vs vehicle accidents vs any other violent crime vs getting struck by a meteor.

Am I really that much of an outlier?

Edit: For those that are downvoting me - I live in a large urban area with large urban area related crime problems that actually has had a terrorism related incident. Mind providing an explanation?

<comment><USER18> >> It asks 1,500 adults what they fear most.

Ask 1,500 citizens in Baltimore, St. Louis, Memphis...

<comment><USER19> Having lived in Baltimore for 7 years, I was far more afraid of crossing the street than guns per se as the violent crime was fairly localized until about a year before I moved. That said, guns ranked far higher than terrorism, which is basically down at the bottom of my list with bears and being crushed by vending machines.

</comment></comment></comment><comment><USER20> Terrorism scales, it is fat tailed distribution (9/11 again, anyone?). Cancer, guns and car accidents - no. Article is plain bullshit.

<comment><USER21> A 9/11 every year still wouldn't make terrorism more dangerous than guns, by my reckoning. That's only a few thousand a year, gun violence kills tens of thousands.

Unless you work in a tall building of course...

<comment><USER20> I think you don't understand what "to scale" means.

</comment></comment></comment><comment><USER22> Everyone here is trying to tackled the stats of gun deaths, but I'm really floored by a survey that shows Americans are more afraid of losing guns than loved ones.

</comment><comment><USER23> There's some rationality to people's fear for terrorism. The impact of a terrorist attack is probably exponentially distributed, like an earthquake attack. Saying no one has died in earthquakes in SF in the last 10 years is not relevant.

Or pandemics – people are afraid of the next Ebola for the right reasons. The 1918 influenza killed 20-50M people.

<comment><USER24> That was after the World War and resulting starvation though.

</comment></comment><comment><USER8> I think the real issue here is that perceptions of many of these risks is as much a matter of tribal identity as anything else. For example, liking guns is a tribal value of "team red" \- therefore viewing it as dangerous is as much an attack on "our team" as it is a rational assessment.

This behavior is hardly limited to "team red". Tolerance of gay sex is a tribal value of "team blue". Yet it turns out M2M gay sex is between 15x and 200x as dangerous as gun ownership. How many people are remotely aware of this?

[https://www.chrisstucchio.com/blog/2016/are_gays_or_guns_mor...](https://www.chrisstucchio.com/blog/2016/are_gays_or_guns_more_dangerous.html)

People suck at risk assessment in general. Apart from scoring cheap points for our team, why focus on terrorism and guns specifically?

</comment><comment><USER25> Leave it to HN to completely ignore the point of the article and nitpick statistics. Guns kill more people than terrorism, period. Regardless of the actual numbers, the article's point still stands.

<comment><USER26> > _Guns kill more people than terrorism, period._

 _People with guns_ kill more people than terrorism. Guns aren't sentient (yet). Guns are inanimate tools; it's a people problem, not a tool problem. Just as you wouldn't say that cars kill people and try to ban cars when it's actually irresponsible drivers (drunk, inattentive, etc) that cause the accident, you can't blame an inanimate object for what its user does with it. Shifting the blame is a political maneuver as old as mankind.

<comment><USER27> Assuming you're not a native speaker, that's an example of synecdoche. Just like The White House does not issue proclamations (it refers to the person occupying the office of the President, who occupies The White House).

One could also say, "The suits are coming for your money." but articles of clothing do not, as a rule, walk around robbing people.

Anyway, I'm pro-gun, but 'guns' kill people is just saying that gun users kill people with guns.

<comment><USER26> The issue is that anti-2nd Amendment folks always want to simply ban guns period, as if that will make the problem go away, hence they use the term "guns kill people". They literally fear the gun itself, not the person holding the gun, and that's a serious problem. The people who say "the White House" in your example indeed don't blame the building for what goes on inside, however the people who chant "guns kill people" invariably believe that the gun itself is to blame, rather than the person behind it. It's irrational and nonsensical, but go into any debate about gun issues and you'll see it all day long.

I recall recently seeing a video (by a progressive minded producer) who laid out several "mean" looking guns (black synthetic stock, picatinny rail, etc) that were actually low power, single shot or limited capacity target guns (one was a BB gun), next to old-fashioned looking but semi-automatic and high powered rifles much more capable of harming large groups of people. Invariably the gun hating types picked out the less harmful weapons as "scary" and said they shouldn't be produced, while they were not nearly as frightened of the wooden stock weapons designed to shoot up to thirty rounds in as many seconds before reloading.

</comment></comment></comment></comment><comment><USER28> Probably because we use guns to "defend" and express our freedom and terrorism only attacks our freedoms.

No one ever says "hey, I want to be a terrorist." Instead they're using their violence to support a personal righteous cause. Terrorism _happens_ to people - it's not something people do.</comment>


Apple warns App Store name squatters (has this happened to anyone else?) - <AUTHOR> http://www.tuaw.com/2010/09/14/apple-warns-app-store-name-squatters/ I reserved a name 90 days ago for a game I was going to do. I've delayed in actually finishing it, and now I'm up against the wall. Anyone else get one of these emails from Apple? <comment><USER2> Quick tidbit:

We had a name locked up. We were planning on using it for a new game. It was registered with Apple. A few days after registering it, another app came out with exactly the same name, but in all lowercase type. App names are case sensitive!</comment>


IM client: Instantbird - <AUTHOR> http://blog.instantbird.org/n48-instantbird-1-0-released-in-11-locales.html

<comment><USER2> This is not Mozilla's project: <http://www.instantbird.com/faq.html#mozilla>

</comment><comment><USER3> The title is inaccurate - Instantbird is a project independent of Mozilla which has been around for a long time.

</comment><comment><USER4> An Android version of this would be nice. I have only found instant messaging apps for Android that has a centralized model. I give all my passwords (Jabber, Facebook, Live Messenger, ICQ, AIM) to a third party that acts as gateway. I'm not comfortable with that.

</comment><comment><USER5> The icon definitely does not make me think _IM client_ , but _MUA_.</comment>


Ask HN: What's your favorite code pun? - <AUTHOR> In a goofy mood today. Feel free to contribute stupid punny code.
make_blind = [eye for eye in world]
function thumb_war(){return [1, 2, 3, 4];} <comment><USER2> #ifdef GetAHearingAid

Appeared in the C/C++ User's Journal Bad C Pun Contenst, 1992. (No, it's not mine. But I remember it...)</comment>


Ask HN: Best Website for Procrastination - <AUTHOR> What your best productivity killer? What make you a compulsive consumer? Where do you like to waste your time on the Internet?<p>One rule only: it shouldn't be reddit, HN, Facebook, Instagram or Twitter. <comment><USER2> Mastodon

</comment><comment><USER3> 9gag?</comment>


DeepMind StarCraft II Demonstration [video] - <AUTHOR> https://www.twitch.tv/StarCraft <comment><USER3> I was left unconvinced (reproducing my comment from reddit):

AlphaStar had 0 cost to sense the entire map simultaneously, and when they introduced the attention/context switching cost (camera control) in the showmatch, it lost.

Also very notable for me in the showmatch was it seemed completely blind and exploitable to some strategies. When AlphaGo played top players, it made a few mistakes, but there wasn't anything obvious that it just couldn't see. Here it just couldn't think of making phoenixes vs. the warp prism harass which shows strategically it isn't near human level yet. It could clearly be exploited by back and forth harassment too (probably has to do with the limited memory those networks have).

Finally, DeepMind were just emphasizing average APM, when it clearly reached totally superhuman levels at times -- even a top professional can't execute 900+ flawless apm in a battle that we saw.

David Silver was clearly expecting the showmatch to be totally one sided (hence his speech that 'this is another historic victory for AI), but I were left with the opposite impression: that strategically top humans are still ahead in this game. This is not the end of the game for humans yet !

<comment><USER4> The original AlphaGo showing (vs Fan Hui) had obvious problems. They weren't catastrophic, it was clearly playing at a professional level stronger than 1d, but it also wasn't obviously superhuman. Lee Sedol could have expected to win his matches, and not been arrogant about it.

The gap between that AlphaGo and the AlphaGo that beat Lee Sedol was probably something like 10 years of human improvement compressed into a couple of months. 500 Elo is huge.

Even if they still have further to go, comparing this to AlphaGo's progress is reasonable. I'm going to live dangerously and make an assumption - <USER2> probably understand Starcraft better than Go, so can see the flaws more easily. Any mistake in Go comes back to something the AI just didn't see.

<comment><USER3> Yea stepping back a little I agree it's a fundamental achievement. It's all about expectations -- I were expecting a Lee Sedol kind of event, and it was more of a Fan Hui (or a bit further) kind of demonstration. A milestone for sure considering how difficult the problem is with various previously unconquered subchallenges (uncertainty, partial observability, massive control space), different but in some ways more difficult than OpenAI's Dota 2 matches.

> I'm going to live dangerously and make an assumption - you probably > understand Starcraft better than Go, so can see the flaws more easily

Correct :) Although I'm not great at either.

This comes closer to opening doors to real uncharted territory in robotics and general agency; it trained in crazy low wall-clock time. But now we're this far it makes me question even more the cost, flexibility, adaptability, of the AI less forgivingly. How much did it actually cost to train? Would it be economical to train one of those for every single task? (e.g. in a factory or warehouse setting), Would it be vulnerable to those exploitable strategic weakness in a real world setting?, etc.

It's definitely not over yet as far as SC2 goes though :)

</comment></comment></comment><comment><USER5> Very impressive... but it seems like the AI relies entirely on abusing blink stalkers which with perfect micro is basically impossible to counter. It is no surprise it can crush pros when it has perfect timing and zero mistakes in using these units.

I think the coolest thing is how the play of AI mirrors a similar style to how pros have developed (Micro harrasing early, early expansions, a very good understanding of when to attack/retreat). It looks just like your average pro..until you see its god tier micro.

Well, after seeing Mana crush it in the live game it seems the AI had zero clue as to what to do... it seems like it calculated it couldn't win a fight so let Mana destroy its entire base. So, just like with the Dota AI we see pros can exploit and win easily once they play around the micro advantages.

<comment><USER6> It had a variety of strategies, not always making a lot of stalkers. And humans can do some _really_ impressive blink micro too up to a certain number of units.

So that's one aspect of it but isn't the main strength.

<comment><USER7> Those were not one and the same agent. If you look at the figure they released on their website the given agent would probably always have gone for a lot of blink stalkers.

<comment><USER6> We're talking about the whole package of the AI, what the entire system is capable of, so that technical detail doesn't affect kmnc's point or mine.

The biggest effect is that it's harder to change strategy midgame, which is not all that critical.

<comment><USER7> It makes the trained agent much less like a human, individual agents are not creative, they've just learned to execute a certain build order. It might turn out that this is enough coupled with flawless execution and micro.

<comment><USER6> "A human agent isn't creative, it just has a set of initial build orders it developed and picks one before the game starts, and after that it adapts to the situation weighted by the units it prefers."

Also the execution of the build order is nowhere near flawless.

</comment></comment></comment></comment></comment></comment><comment><USER8> I only had a chance to see the live game, but very impressive stuff, especially in the early game! However, it does seem to have the same issue as all other AIs in that it is inflexible and fails to adapt to unusual situations - As the commentators pointed out, it kept building oracles when being constantly harassed by an immortal drop, whereas any amateur player would be able to react more effectively by building a single phoenix.

It also fails to recognize patterns - MaNa was able to find and repeatedly abuse a border between two strategies: whenever he was not actively dropping, AlphaStar would attempt to move out and push, then immediately retreat to defend when being dropped, whereas a human would recognize the reoccurring theme and either keep pushing or stay in their base.

While not groundbreaking, still exciting to see an AI that can hold its ground against pro players - it certainly demonstrates the potential of machine learning for constrained problem spaces.

</comment><comment><AUTHOR> Here is another link (YouTube) that allows you to go back in time if you've missed anything: [https://www.youtube.com/watch?v=cUTMhmVh1qs](https://www.youtube.com/watch?v=cUTMhmVh1qs)

</comment><comment><USER9> The live exhibition match definitely made Alphastar look like a machine making the decisions, not a super smart being. The micro was obviously impressive but that should also be the easiest part to master. I share the sentiment that DeepMind is hosting big events to paint a very one-sided picture of man vs machine, so this last win of mana feels oddly satisfying.

<comment><USER10> It is a little disappointing that Mana's win was achieved in part by simply exploiting Alphastar's poor response to the immortal drops by doing it over and over again. In contrast, Lee Sedol's win versus AlphaGo involved profound strategy and a particularly inspired "divine move" that humans get to brag about.

<comment><USER11> Lee Sedol "divine move" actually doesn't work, even human top players would have punished it.

It actually was just a really weird mistake in AlphaGo

<comment><USER10> As they say... there are no good moves in Go/chess/zero-sum games etc. There are only bad moves.

That doesn't prevent professional players such as Gu Li 9p from describing it as a divine move though. And it does feel good for Team Humanity.

</comment></comment></comment></comment><comment><USER12> Wow, Alphastar was able to 5-0 vs TLO (when he was off racing) and 5-0 vs Mana in an impressive manner. I am quite impressed that DeepMind has been able to take down Go and now Starcraft. From here on out, if DeepMind makes an announcement about a demonstration of X, I expect them to beat the top humans at X.

Edit: In the live game Mana is able to beat Alphastar. Alphastar was trained with a more limited camera than the previous games. Mana was able to harass Alphastar with a warp prism then push in and win.

<comment><USER13> TLO and Mana are good players but Im not sure they fulfill your criteria of top humans at X

<comment><USER12> According to a site [1] Mana is 19th. While that is probably overly high, I would say he is easily in the top 200 Starcraft 2 players in the world. I would also say that to get from beating a top 200 human to beating all humans is much smaller than from scratch to beating a top 200 human.

[1] [https://www.gosugamers.net/starcraft2/rankings](https://www.gosugamers.net/starcraft2/rankings)

<comment><USER14> Aligulac's had Mana around 50th in the world consistently for a recent 12 month period, so I think that's a more reasonable claim, and I'm happy saying that the 50th best player is a "top player in the world".

<comment><USER15> Is Mana the best Protoss player in Europe?

<comment><USER14> Second-best, probably. Best Protoss players, approximate from older Aligulac data:

1\. Classic (Korea)

2\. Zest (Korea)

3\. herO (Korea)

4\. Stats (Korea)

5\. Neeb (USA)

6\. Dear (Korea)

7\. Trap (Korea)

8\. ShoWTimE (Europe)

9\. MaNa (Europe)

</comment></comment></comment></comment></comment></comment><comment><USER16> I am somewhat disappointed that they stream only hand-picked replays. For a big, announced presentation, they should be at a stage to stream live games (like OpenAI did with Dota).

However, apart from that great work by Deepmind and I am excited to follow the progress in this area.

<comment><USER17> They're streaming a single live game right now! They explained that the research build of the game being used doesn't have an "observer" mode so it's not quite suitable for streaming live games — and, in fact, the games that they were showing were played over a month ago. (The current live game is being shown from the human player's point of view, and as such is a bit… dizzying.)

</comment></comment><comment><USER18> Some of the commentary shows that the UI is a barrier . The fact we can understand the strategies, but cannot physically make it happen shows that at least some of the advantage is just the precision of the inputs.

Could be a new way to play SC2 like games where we can better communicate our intentions to the game. For example, make a type of move action where the stalkers automatically retreat and stop to fire, instead of having to do move, attack, move, attack series of inputs.

<comment><USER19> This thought process (of the UI limiting the player) is a valid point when we are talking about Human vs. AI strength and weaknesses in RTS games. However, when pitting one human player against another, the UI limitation actually _adds_ strategic depth to the game. Unlike pure strategy games like chess, in Starcraft when you have to move, attack, move, attack, it puts a physical burden on the player. This physical burden to work around the limited UI allows one player to outperform the other on both a strategic and physical playing field, in real time. If both players were freed of their physical shackles, it would become a much more boring display of pure strategy, which eventually would be "solved" and the game would cease to be fun.

If you look at the difference between Starcraft 1 and Starcraft 2, the two most significant UI changes are the ability to select more than 12 units at a time, and the ability to "multi-cast" spells in sequence when more than 1 spellcaster is selected. These two small UI improvements greatly reduce the skill gap between an average player and a "pro" player in Starcraft 2, to such a degree that many Starcraft 2 pro players went back to Starcraft 1, where their fast reflexes give them a much greater advantage against other players due to the limited UI. So an improvement to the UI would help human players beat AI, but it takes a strategic element out of the game when considering human vs. human.

<comment><USER18> I agree there are pros and cons to the physical mechanic. For example misclicks become a part of the game, whereas the RNG would be fair to each player about errors in preprogrammed walk/attack patterns.

</comment></comment></comment><comment><USER20> This is mad impressive, for sure. With most AI problems, I can at least comprehend the approach, and the necessary combination of models. Not so much here.

My first question is what is the input to the AI? Is it the raw pixel array of the display? Or does it get API-level readouts of what's happening? Because implementing the CV just to segment the display output in real time is crazy enough. I would assume the latter.

I think this basically proves that any problem that can be exhaustively simulated is solvable now. This may mark a tipping point, as every problem for which simulations exist (essentially infinite labels) is solved - then the balance will tip back toward making faster and more accurate sims (think multi-scale first principles physics stuff).

<comment><USER21> Blizzard released a client with an output accessible to machines, but still preserving fog of war. See here:

[https://deepmind.com/blog/deepmind-and-blizzard-open- starcra...](https://deepmind.com/blog/deepmind-and-blizzard-open-starcraft-ii- ai-research-environment/)

Here's what I want to know, were these agents developed from scratch a la AlphaZero in chess, or did they have to create a number of abstractions in order to get the AI to start learning the game? In the initial demonstration they could hardly get the AI to mine minerals or do anything. How did they make the jump to actually good play?

<comment><USER22> They mentioned that they initially used imitation learning on human replays.

</comment></comment></comment><comment><USER23> The AI makes some _awful_ decisions, such as building five observers. This calls into question its "understanding" of the game. It looks like a lot of its ability comes from micro, which it's unsurprising a computer can do better than a human.

This is impressive, but with a lot of caveats. DeepMind's work on chess and go was impressive with no caveats whatsoever.

<comment><USER24> I do believe the live match was with a newer version of the agent that hadn't been tested against human yet

</comment></comment><comment><USER24> I'm not proficient in Starcraft, but if they have to make Pros play against 5 different agents for a Bo5 is it because the same agent would merely repeat the same game overall and the human player would be able to see through its strategy?

AFAIK at least for Go/Chess DeepMind wasn't handpicking agents to send against human opponents, but it was simply a trained agent who would try its own strategy and respond to the opponent, in this case isn't it like the single agent only ever plays a single type of meta strat? If so, I think this is a bit less impressive than what I had predicted.

<comment><USER25> There's a rock-paper-scissors like aspect to StarCraft openings where you essentially have to randomize your strategy so that the other player can't blindly counter what you're doing. I assume each of their agents learns one particular strategy; in that case, they could simply create a "meta-agent" that acts like one of their trained agents at random (probably using some weighted distribution).

<comment><USER24> Well, why wasn't this implemented then? For an hyped and live streamed event I'm expecting to see something that blows me away, not hand picked agents still in embryonic stage

</comment></comment></comment><comment><USER26> 10:0 AI wins. Precision micro control of units to save them from dying.

</comment><comment><USER27> This was incredible. The games against MaNa even more so. TLO games were like MNIST, but AlphaStar going against MaNa was like ImageNet level honestly. Hats off to DeepMind.

</comment><comment><USER28> I haven't played SC in years. Surprised that it is still going strong considering I haven't heard much SC news in a while. I remember one trick against the SC AI was to send a probe to the AI's base and lure all the AI's probes out of its base. That was the easiest way to win against AI back then. Comparing DeepMind/Alphastar now to what SC AI was a decade ago really puts AI advancement into perspective.

</comment><comment><USER29> Twitch.tv chat is full of shit-posting no doubt, but I did find some of the comments amusing:

      - "You only have 50 GPUs in 2019, LuL"
      - "AlphaStar is a cyberbully"
      - Many were claiming the AI had "1500 APM", not sure where that idea came from
      - and lots more

<comment><USER30> There were moments during clutch blink micro where the onscreen APM number for AlphaStar exceeded 1000.

</comment></comment><comment><USER25> I'm starting to get annoyed with these DeepMind publicity stunts. They don't release any code, and don't let anyone verify their results. Their chess AI beating Stockfish involved some at least a bit questionable setup. And here? I'm a big fan of TLO, but he's currently not even in the top 50 even with his main race. With Protoss, he's clearly making amateur-level mistakes. Why choose this setting to show off your supposedly superhuman AI?

(Edit: This comment was made during the stream and it just looks like my point will be addressed before the stream's even finished, they'll let the AI play against a true top Protoss. Yeah!)

<comment><USER31> The fact that the community has been able to use the published paper to replicate all of AlphaZero's results in both chess, go (and a number of other similar combinatorial games) and get similar performance should lay your concerns to rest.

<comment><USER32> Can you provide some links?

<comment><USER33> LeelaChess is one example for Chess.

[https://github.com/LeelaChessZero/lczero](https://github.com/LeelaChessZero/lczero)

<comment><USER32> This project actually proves the point of the root comment. The community spent tons of time on tuning/training this network, and it still routinely loses to Stockfish, which runs on inferior hardware. It illustrates that:

1\. Deep mind kept a lot of information about their methods undisclosed.

2\. Despite all the claims of generality, the algorithm requires _insane_ amounts of fiddling to train. Just read their blog.

3\. The hype around AlphaZero crushing every other algorithm in chess is overblown. It's competitive, but not clearly superior.

Still, Kudos to people running Lela project for doing what DeepMind should have done - describing how things really work and testing in real-life conditions.

</comment></comment></comment></comment></comment><comment><USER34> I'm having a hard time knowing if it's using a single agent of the five top agents or an ensemble of their five agents.

<comment><USER35> It sounds like each match in the Bo5 is against a different agent. It's a hair dirty, but I don't think it's too bad because the same kind of random- selection strategy is just as possible "in the wild".

</comment></comment><comment><USER36> The singularity is near (5 yeats away max)</comment>