Racket v7.2 - <AUTHOR> https://blog.racket-lang.org/2019/01/racket-v7-2.html <comment><USER3> Mike Sperber used Racket in his excellent 35c3 talk "How to teach programming to your loved ones": [https://media.ccc.de/v/35c3-9800-how_to_teach_programming_to...](https://media.ccc.de/v/35c3-9800-how_to_teach_programming_to_your_loved_ones)

From the abstract: "A word of warning: The resulting approach is radically different from most teaching approaches used in universities and schools. In particular, it avoids teaching purely through examples and expecting students to develop the skills to arrive at the solutions on their own. Instead, it eaches explicit methodology that enables students to solve problems of surprising complexity on their own, whether they are 11 or 55, whether in a classroom, a training facility, or your home. Extensive documentation, material, and software to support this methodology is available for free."

<comment><USER4> Thanks for sharing. Nice. I'm not a programmer but I have taken many courses all over the web (I think I only lack practice). This talk reminds me of the Edx course on functional programming using DrRacket. As the talk suggests about the boring and bureaucratic aspect of the recipe design, I think that's exactly the reason why I couldn't finish that Edx course twice, though I am convinced that this design/recipe methodology to learning to program, is the right solution (which is absent from the pedagogy of a lot of courses). This talk makes me want to try and take that edx course again, the third time!

<comment><USER5> If a methodology doesn't motivate you to actually do the work (i.e. finish the course) no matter how intuitive it might be, it will not work. That said of course everyone is different, and what motivates one person, may not motivate another.

</comment></comment></comment><comment><USER6> Racket is such a cool project. I keep telling myself I'll find the time to do something serious with it, but I never get around to it.

One minor bit of criticism - would be it be so hard/expensive to hire a designer to do some minor touching up of the DrRacket GUI? It looks like a toy, and the icons didn't even look good in 1998.

I'll balance this criticism with the remark that any language/platform that manages to a) add, ex-post, a type system, b) fix the Gordian knot of modules _and_ macros, and c) has the audacity (combined, curiously, with humility) to just swap out the entire backend to eek out more performance, deserves my respect. In addition both Flatt and Tobin-Hochstadt give excellent presentations where it's impossible not to notice their passion for Racket. They're definitely among my nerd heroes right now.

<comment><USER7> > and c) has the audacity (combined, curiously, with humility) to just swap > out the entire backend to eek out more performance

Unfortunately they are not doing it for performance reasons. They are doing it solely to make the code base cleaner and easier to maintain.

Based on their most recent blog on the subject ([https://blog.racket- lang.org/2019/01/racket-on-chez-status.h...](https://blog.racket- lang.org/2019/01/racket-on-chez-status.html)), the new backend is almost uniformly slower to load, takes up twice as much memory, takes more than twice as long to build, takes twice as long to compile Racket code, and the compiled code generally runs slower than it used to. (They expect that this last one will improve, but they have never indicated that they expect it to actually match or exceed the speed of code compiled with the old backend.)

Also, the new back-end, by design, permanently removes support for the Racket C API.

This trade-off is hard for me to understand. I don't maintain Racket, so I don't have any idea how much effort this will ultimately save those who do. But I do know that I the main thing holding me back from investing more development time in Racket is its poor performance compared to languages like PHP, Python or Go; and I have never seen explained, and can't even imagine, what new features the maintainers will now be able to implement that would actually make Racket development more productive or enjoyable.

<comment><USER8> The new backed is overall faster according to that post. In addition, looking at raw Chez, the results are even more one-sided. Chez is _always_ faster and often 2-8x faster. New racket is usually faster and where it isn't is mostly due to new IO. Sure, compile times get bigger -- Chez is doing _way more_ optimization passes than Racket (Chez is the only scheme I know of that can get close to SBCL in performance).

[http://blog.racket-lang.org/img/posts/2019-01-29-racket- on-c...](http://blog.racket-lang.org/img/posts/2019-01-29-racket-on-chez- status/pict.svg)

According to them, fixing things takes much less time and is much easier to understand. For a system where lots of development is free, ease of understanding and fixing is extremely important.

> But I do know that I the main thing holding me back from investing more > development time in Racket is its poor performance compared to languages > like PHP, Python or Go

Racket is slower than Go because racket is dynamically typed, is a much higher-level language, and has to implement continuations. Racket is _much_ faster than python or PHP.

My big issue with racket is dev tools. DrRacket isn't very good IMO. They need to make a server that implements the Language Server Protocol with some additional hooks for more dynamic lisp stuff. At that point, devs can choose to use all kinds of actually good editors (sublime, VS Code, Vim, Emacs, IntelliJ, etc) for coding. They can even add the LSP to DrRacket and continue to use it.

[https://langserver.org/](https://langserver.org/)

<comment><USER7>
        The new backed is overall faster according to that post.

No, according to that post, the new back-end itself is massively slower than current Racket by every single measure shown. To reiterate, I'm talking about startup and load times, memory use, expand and compile times, and build times (i.e. time to compile the back-end itself). All slower. (Are you sure you're not referring to _code compiled using_ the new back-end?)

I grant that there is some benefit in that the longer compile times result in an improvement in some benchmarks, but that doesn't negate that the new back- end is still slower than the old one by every measure.

> Racket is much faster than python or PHP.

This is funny because although you will find benchmarks out there to support this point, in my experience of writing and using Racket programs it has never hold up. Most recent example: I participated in Advent of Code this year, and there was almost never a Racket solution posted that wasn't ten times slower (and in my opinion harder to read) than the simple & idiomatic Python solution.

I love the Racket language, and there are some DSLs like Pollen that do things I simply can't imagine attempting anywhere else. But it's for sure my last choice for speed, based on personal experience.

<comment><USER9> > Most recent example: I participated in Advent of Code this year, and there > was almost never a Racket solution posted that wasn't ten times slower (and > in my opinion harder to read) than the simple & idiomatic Python solution.

Can you point me to some examples of this? I haven't done AoC and so don't know where to find solutions posted to compare. It should be very rare for idiomatic python or php to be faster than idiomatic racket.

</comment></comment></comment></comment></comment><comment><USER10> Matthew Flatt did an excellent talk "Incremental Parallelization of Dynamic Languages" on Racket [https://air.mozilla.org/incremental-parallelization-of- dynam...](https://air.mozilla.org/incremental-parallelization-of-dynamic- languages/)

There's a lot of useful discussion in here about parallelism which also applies to Ruby, Python, Lua etc.

<comment><USER11> Is this video available without a login?

<comment><USER12> Using Firefox on Android with uBlock Origin enabled, I was redirected to some "onlinexperiences.com" site that displayed "System Check" and then a constantly growing number of lines containing only "Browser".

Then I tried the stock Android Browser and it passed the browser check, but redirected to a login page.

Going back to Firefox and disabling uBlock Origin, I was able to access a description of the talk and the video itself. So I conclude that the video is available without login, but you have to use Firefox and allow yourself to be tracked.

Pretty grating "online experience" for something hosted on a mozilla.org subdomain.

Edit: the video file is here: [https://airmo-7feeef12f503ef5d.s3.amazonaws.com/2014/02/06/4...](https://airmo-7feeef12f503ef5d.s3.amazonaws.com/2014/02/06/4q6e6u-hd_mp4.mp4)

<comment><USER13> Very bizarrely for something on mozilla.org, it incorrectly believes my firefox is out of date: [https://i.imgur.com/BRNBDPj.png](https://i.imgur.com/BRNBDPj.png)

I think there must be a cultural disconnect between how people at Mozilla use firefox, and how users like us use Firefox.

<comment><USER14> AFAIK air.mozilla.org is some ready-made product by a different company (maybe even run by them), not developed by Mozilla

</comment></comment></comment></comment></comment><comment><USER15> I just wanted to say that Racket docs are the best docs I have ever seen. It feels they document everything -- so much detail. Treasure trove of knowledge. Thanks guys!

</comment><comment><USER16> Does anyone use this in production? Will this be a good platform to develop a DSL for a web app?

<comment><USER17> We ([https://linki.tools](https://linki.tools)) use it for our main development tools product - 100% Racket in production. Check S10 ([https://linki.tools/s10](https://linki.tools/s10)).

Racket is an absolutely gorgeous language. It's the kind of language that might look complicated but the important thing is to start with the basics. Yes, there are complex features in the language and big words that might be scary : continuations, impersonators, collapsible contracts, macros. However most of the time you don't really need these features.

Even the basic features of the language are enough to make your software shine. After you have a basic grasp, start to tackle other features of the language refactoring your code as you go.

Another great feature is the community. racket-users mailing list (hosted in googlegroups) is a great place to start asking questions.

You'll have a lot of fun. Enjoy your time in Racket lang. #not-a-typo

<comment><USER16> So, I am an experienced developer but new to Lisp based stuff, which seems to be what racket is based on. Can you suggest any books to learn racket.

edit: Spelling

<comment><USER18> Seems like the most common answer to this might be SICP (Structure and Interpretation of Computer Programs -- you'll find course videos pretty easily from Google; the ones from the authors are really great). Note that it's based on Scheme, which is a ancestor of Racket, but Racket has a language pack that papers over the differences and works with the code from the book. Official course website: [https://mitpress.mit.edu/sites/default/files/sicp/index.html](https://mitpress.mit.edu/sites/default/files/sicp/index.html)

You might, as a novice coming to Racket, find "Realm of Racket" to be more approachable as an intro: [http://www.realmofracket.com/](http://www.realmofracket.com/)

<comment><USER19> > Seems like the most common answer to this might be SICP

Please don't. SICP is beautiful and all, but it's neither an intro nor practical/immediately useful. There's a lot of enlightenments to be had by reading it, but they have very little to do with Racket specifically. IMO, it's a bad book if your purpose is learning Racket.

> You might, as a _novice coming to Racket_ , find "Realm of Racket" to be > more approachable

Or, as an _experienced programmer_ , be bored to tears by the slow pacing and didactical style. It's a great intro to programming and to Racket, but more focused on the former, which makes it ill suited for experienced devs who want to learn Racket.

<comment><USER18> Please don't what, have an opinion?

I read SICP as an experienced programmer and I didn't find it impractical at all; in fact, it kickstarted my interest in other lisps.

I read Realm of Racket as an experienced programmer (after knowing Common Lisp and Clojure well) and it was entertaining and, yes, a gradual introduction to Racket.

I'm sorry if you disagree, but was answering the question that was given with a couple thoughts that might be beneficial. I'm glad you feel confident enough in your interpretation of what was being asked and the OP's personal background and motivation to flame someone else without, I don't know, answering the question.

EDIT: I see you did answer him below, but my general response is still valid.

EDIT 2: Your response makes more sense given context. Sorry I got internet angry a little too quickly.

<comment><USER19> And on a more general note - let's leave the misunderstanding to the separate thread - I'm glad you liked the books! I'm not saying you can't enjoy them - far from it - but if your goal is to just _learn Racket quickly_ (where I interpreted "experienced dev" as "short on time working adult") then they are not the best resource for that. SICP is not even about Racket at all and RoR includes a lot of introductory material you wouldn't need. Instead of learning by accident, ie. reading weakly related material and hoping that an understanding will somehow form (which seemed to be default mode in education), I prefer using materials which are strictly on topic and are dense enough to be efficiently absorbed, but not so dense that it takes a day to go from one page to another. And to that my answer is: Wiki, tutorial&cheatsheet and the docs.

What is obvious is that YMMV - I'm just saying what I'd do if I wanted to efficiently learn Racket today. That's it.

<comment><USER18> Yes, I totally agree it comes down to YMMV. Everyone's learning style is different -- some like dense documentation, some like book-style progressive walkthroughs. I certainly didn't learn CL by reading the HyperSpec, for instance... :-)

<comment><USER19> Yeah, that's why I included the "but not too dense" part ;) Personally, I actually did learn Common Lisp mostly from HyperSpec (plus reading code - <USER2> used StumpWM for a while and wanted to script it), but at that point it was my 4th Lisp (after PLT Scheme/Racket, Emacs Lisp and Clojure) and I was well prepared for it, I think, because of my focus in PL research (hobbyist). I certainly wouldn't say that HS is the way to go for new CL programmers without special preparation.

But, Racket reference docs are not a language definition like HS, RNRS or the Dylan book. The tutorials especially are quite friendly, but the reference is also full of examples, overviews, summaries and introductions, along with the links to the Guide - which can further help in comprehending the content (but only if needed, otherwise they stay out of the way). They're basically amazingly well done and I think more people should read them, if only to learn something about how to write docs and technical prose in general... :)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> I've used Racket in the past. Personally, I'd still never use it for production because the learning curve is fairly steep AND as this post highlights - there are still bugs being worked out in basic features like "set".

However, overall I like the language. So, overtime I think it'll have its day in the sun.

<comment><USER21> > there are still bugs being worked out in basic features like "set".

You are misreading the release notes.

What was fixed is a Redex model (a tool used in semantics to model computer languages). A change to the modeling of `set!` (assignment) was made. It has no impact on Racket itself.

<comment><USER22> Really? Then as written it's very misleading "led to some bug fixes in Racket's implementation of letrec and set!."

<comment><USER23> [Edit -- misread comment.]

<comment><USER24> If it is in fact the case that only some redex models of `letrec` and `set!` were fixed, then it is indeed misleading that the release notes say "Racket's implementation" of them was fixed.

Unless you're the one who did the work, I'd rather trust the release notes than your unsourced assertion.

That said, just because a bug was fixed in an important function shouldn't be an indictment against the language. Racket is stable and productive, and formal modeling can reveal all kinds of corner cases which may not have been exposed in typical use, and may not have security implications. Maybe it was edge-case performance, maybe garbage collection, the release notes simply don't say.

I'd rather use a language whose authors improve their tools to discover and fix issues than one where this doesn't happen.

<comment><USER23> Ahhh, my bad. I thought you were the same commenter as the first guy, and I doubly goofed by misreading the comment in the first place. The dangers of commenting before coffee. You're right, the difference between redex models and racket's implementation of them would be confusing, and I don't have enough direct knowledge to provide any insight there.</comment></comment></comment></comment></comment></comment>


ThinkwithGoogle: What Influences the Films We See - <AUTHOR> http://imgur.com/a/O7j2P <comment><USER2> Link for the original infographic [PDF]: [http://think.storage.googleapis.com/docs/behind-the-box- offi...](http://think.storage.googleapis.com/docs/behind-the-box- office_infographics.pdf)</comment>


Show HN: HTML Email Templates for Startups - <AUTHOR> https://niceverynice.com/blink-email-templates/ <comment><USER2> Don't write HTML messages. Write instead short, concise plain text mails with a clear question for action of the recipient.

And let people unsubscribe by using standard mailing list headers or a hyperlink which does _not_ lead to a login form. It is in your interest: If your mails are marked as spam in big services (Gmail...), your reputation is suffering.</comment>


Ask HN: Has anyone tried to debunk the myth that Facebook is listening? - <AUTHOR> For weeks and months, there has been the same conspiracy about Facebook listening to their 2 Billion users to serve targeted ads.
Countless questionable youtube videos, reports of all sorts by people who have no idea what it would entail to perform such a stunt on a large scale.
After googling extensively, I still can't find any real scientific proof that it's either true or on true. It's mostly about some people relating their funny experience and mostly about Facebook saying "No we don't"
Anyone familiar with Charles Proxy would know it's pretty easy to spy on the traffic going from an app to the backend. I work in Facebook advertisement and I've been doing it for various reasons already many times. I've never seen anything that would like a speech datagram, but then again, it wasn't what I was looking for when listening to the Facebook app.
I would expect that given Google and Apple should be scrupulous about what the Facebook app does and doesn't, there should be a host of people who've been looking into that urban legend a number of time. Also the data plan of many people would simply explode too quickly for this to be true.
With my colleagues, we've been wondering if it would be possible to rely on a local text-to-speech engine running on the phone. Needless to say that would drain the battery pretty quickly and the dataset needed in the app would be pretty huge... But is it? And would it really drain the battery? More than Pokemon or the Facebook app...?
Who among you guys is a seasoned user of Charles and could run the experiment a tad further? <comment><USER2> The lack of actual responses to your question here is a bit entertaining. "Of course they are not", "it's not possible", "iOS/Android is safe" etc. Almost like it is offensive to ask.

I can't help but remember my incredulous reaction to ECHELON in the 90s and how it turned out to be not just true, but much worse than the original "conspiracy theory".

A very relevant example: [https://jscholarship.library.jhu.edu/handle/1774.2/36569](https://jscholarship.library.jhu.edu/handle/1774.2/36569)

<comment><USER3> This post was built to influence the largest number of people possible. The title is worded to reach people that don't click with the suggestion that the accepted view in the community is that they aren't spying. It's also by a newly-created account made by a Facebook Ads employee.

The microphone privacy invasion rumor has spread so far without evidence because people are tired of the 1000 other privacy invasions for which there is evidence. They don't care whether or not this specific instance is true. People are tired of FB being openly scummy at every other turn. FB is the least respected tech company for a reason.

<comment><AUTHOR> Happy to debunk this in whichever way you want! I definitely don't work for Facebook. Also I have been consuming HN content for years without contributing. There has to be a first day...

I do work closely with Facebook (For a Facebook Marketing Partner called Smartly.io) and we collaborate closely on certain aspects. I think I have a very deep understanding of what Facebook is capable of and that's the reason why I want to debunk this. Also, I am really tired of hearing the questionable reports.

Look me up if you which: [https://www.linkedin.com/in/momeunier/](https://www.linkedin.com/in/momeunier/)

</comment></comment></comment><comment><USER4> My answer to this has always been "Why would they need to?" It drains battery, it sends a lot of data, and would be a huge scandal. But you are already telling them where you are, who you're with, and they have information about your credit, etc.

Instead, I've been using this as an opportunity to teach people why big data is scary. In the past people often said they didn't care that Google could, and do, read their emails. Often responding with the ironic "I have nothing to hide" quote, or "I don't care, my stuff is boring." This pervasive rumor, of Facebook/Google always listening, has facilitated this conversation immensely. I've been able to better explain it to many who are not tech or statistic savvy in the least.

I don't believe Facebook is listening, because they don't need to.

<comment><USER5> Or in other words, they _are_ listening, just not to your voice. Their product is an intelligence-gathering apparatus that works at scale without microphones or other traditional surveillance tools.

<comment><USER4> I'd phrase that as "they're watching" not listening. More like having a private eye tail you. They can't hear exactly what you say (well maybe) but they sure do see everything you do.

</comment></comment></comment><comment><USER6> I was at lunch with a couple friends and they were making fun of Juicero. I hadn't heard of it at this point. I didn't look it up on my phone, but at least one of my friends did. That afternoon I started seeing Juicero ads non- stop on Facebook. Was Facebook listening or did they connect the dots that my phone was in the same restaurant as friends who were Googling Juicero and figured we had been talking about it?

Another time I was on a road trip with a friend, driving through a food desert. We were talking about our food options -- stuff we never eat like McDonalds, Wendys, etc. Guess what pops up on Facebook moments later? An ad for Wendys! Were they listening? Or did they just connect the dots that it was lunch time, that we'd been driving for a long time without eating & that Wendys was one of the only options around?

In both instances, there were non-microphone explanations but creepy/impressive nonetheless.

<comment><USER7> >Guess what pops up on Facebook moments later? An ad for Wendys! Were they listening?

If you saw an ad for Wendy's in any other context, would you have been surprised?

I saw an ad for Wendy's shortly before coming to comment on this post. Are HN's advertising algorithms predicting the future, or is it just a coincidence due to the overwhelming volume of fast food advertising?

<comment><USER6> I can't remember seeing one before & haven't seen one since.

</comment></comment></comment><comment><USER8> Every one of my friends, including me, has a story about how they used a phrase in conversation that they don't typically say ("Renaissance Faire" in my case, which I have never attended and generally have no interest in), and then seeing an ad for it on either Facebook or Instagram right afterwards. This is purely anecdotal, of course, but it is creepy anyway. The only way to stop this "myth", if it is one, is for Facebook to stop doing whatever it is they do instead of listening to us to get to this unnerving level of targeting.

<comment><USER9> Alternate explanation: the person(s) you discussed this with did some google'ing and browsing. The tracking cookies do their thing and since you and those persons are linked, you end up with the ads served.

<comment><USER10> a good alternative hypothesis, but also one that should be proveable, at least in some cases.

designing an experiment to test this would be quite easy.

ultimately your explanation could exist alongside audio snooping, perhaps even helping to resolve areas of ambiguity...

</comment></comment></comment><comment><USER11> The excellent "Reply All" podcast had an episode about it: [https://gimletmedia.com/episode/109-facebook- spying/](https://gimletmedia.com/episode/109-facebook-spying/)

</comment><comment><USER12> It's trivial to debunk by observing that many people who say they've experienced this are using iPhones. On iOS, apps can't silently use the microphone in the background. A background app using the microphone is always accompanied by a red status bar saying that they're doing it. This doesn't show Facebook listening, therefore we can conclude that they're not, at least on iOS.

It's possible they might be doing it on Android, but once you show that a lot of people are imagining things, it's a small leap to thinking that they all are.

<comment><USER13> Wasn't there just a story about Apple giving Uber special permissions (which were not turned off after they were no longer needed) so they could do stuff on the Apple watch? Is it that much of a stretch to think they would also give Facebook special permissions?

<comment><USER12> Yes, it is that much of a stretch. Apple temporarily gave Uber that special permission in order to make their Watch app work better for their users. It's extremely unlikely that Apple would give Facebook special permission in order to spy on users to no benefit to the people who actually pay Apple money. And somehow it's gone unnoticed all this time.

<comment><USER12> I didn't realize it when I wrote the above, but this makes my case much stronger: these special entitlements are listed as part of the app. It's far from obvious to the end user, but people who know how to look at them can do so. Either nobody knowledgeable has ever looked at Facebook's entitlements, or it doesn't have one that would let them do this.

</comment></comment></comment></comment><comment><USER14> All I know is that things that I have talked about with my phone around 1-2 days prior, I suddenly see ads for. Things I did not Google or mention on the Internet. In one case I started seeing ads on Instagram for a product that I posted a photo of and did not even include the product's name in the post. Dishwashing liquid that I would never even buy (I'm not the target user so it wasn't target marketing).

It's all a little too much for me to believe it's a coincidence.

</comment><comment><USER15> The burden of proof falls on the people making claims that facebook is listening. Absent that, it seems extremely unlikely that facebook is recording audio and no one has posted in outrage about it - streaming audio would be quite conspicuous.

Even more troubling than audio recording in this case is that facebook has so much information about you that they don't need it. The idea that facebook knows the approximate content of your conversations/thoughts to the point that it seems like they're listening should be deeply troubling.

If facebook knows the content of your conversation, seemingly before or at the same time that you have it, what does that mean for free will? Agency? (Obviously free will is bs, but most people I've talked to refuse to acknowledge that - is this a wake-up call?)

What other predictions can they make? With the level of information given to facebook (browsing history, precise location, when you're asleep and when you're awake, and possibly much more, like your cell account info and the TV you watch) they can build a very complete picture of your life, and may even know things about yourself that you don't know.

Of course, when facebook is actively listening to you (e.g. for facebook messenger) all bets are off. They already read your conversations anyway, so it's not a far jump.

</comment><comment><USER16> I don't think FB is listening because all the stories I've heard can be explained by their graph.

I think it's hard to debunk because people don't recognize how powerful their knowledge graph is at this point, and simultaneously underestimate how hard general-purpose speech recognition is, even with studio-level audio setups. And especially to a non-programmer, I think it seems so much easier to just figure out speech recognition than to maintain a huge knowledge graph about billions of people, their connections (explicit and implicit), their current whereabouts, the sites they are visiting, and the text they literally give to Facebook in the form of messages etc. But of course, each one of those things is a tractable problem, and can progress independently of the others, until all of a sudden it's so good it seems like they must be inside our heads, or at least listening.

But here's the thing: I think all that big data is actually waaaaay creepier. If they were just listening in and showing relevant ads, that'd be one thing. But instead they have all this data going back years, and can make all these inferences from the data. Just imagine what inferences could be made about non-advertising topics!

</comment><comment><USER17> I proposed a thought to Reddit, but have no proof of its possibility either technically or practically.

The people we talk with are generally the people we are connected with on social media. It's feasible to me that a conversation happens and someone in the group makes a search, which then maybe causes algorithms using location data to push those ads to people in that location.

Further, what's being talked about is probably being talked about and searched by others in the area and/or with the same interests, so even if it isn't localized quite so much the possibility of what's being talked about to generate ads is heightened.

Finally, there's the confirmation bias and recency bias at play. Once something is known or on mind, it's more likely to be noticed. They may have already had those ads coming in and only noticed them after talking about it. Or, the ads might have even caused the person to subconsiouciously think about the thing.

The psychology at play in advertising is advanced.

</comment><comment><USER18> "Facebook does not use your phone's microphone to inform ads or to change what you see in News Feed. Some recent articles have suggested that we must be listening to people's conversations in order to show them relevant ads. This is not true. We show ads based on people's interests and other profile information – not what you're talking out loud about," said Facebook in a statement last year. "We only access your microphone if you have given our app permission and if you are actively using a specific feature that requires audio. This might include recording a video or using an optional feature we introduced two years ago to include music or other audio in your status updates."

Source: [https://www.forbes.com/sites/amitchowdhry/2017/10/31/faceboo...](https://www.forbes.com/sites/amitchowdhry/2017/10/31/facebook- ads-microphone/#1f13abc3534d)

</comment><comment><USER19> Facebook listening to their customer's concerns about privacy? Yes, that myth has been throughly debunked.

</comment><comment><USER14> Maybe local text-to-speech is not plausible given the heavy processing and battery drain. What if instead there is a list of words/brands being listened for; my phone is always listening for "OK, Google."

</comment><comment><USER20> I can't speak for Android, but there are a number of precautions on iOS.

The first one is that iOS gives users very fine grained control over what apps are allowed to use the microphone. It's not just a list of permissions, it asks specifically with a system dialogue box whether you want to allow an app to have permission.

Second, the status bar turns a very obvious red color when an app is using the microphone when it's in the background.

If FB was able to bypass both of those safeguards without Apple knowing, it would be a major story.

</comment><comment><USER7> Install the facebook app on lineageOS, open up privacy guardian, and see for yourself exactly how often it uses your microphone. It's definitely not listening to everything you say.

<comment><USER21> Just pointing out that this is far from a conclusive invalidation technique. Too many ways such spyware could still exist or operate.

<comment><USER7> i realize i'm fighting a losing battle by posting in a conspiracy theory thread, but okay: what are those ways that the facebook app could listen to you without the OS knowing it's using the microphone?

<comment><USER21> I don't know, but one would need to thoroughly audit the code to find out one way or another. One would not draw conclusions about the non-existence of such a feature just because they've made exterior measurements (exterior to the black box blob of fb code) that don't give affirmative indication. Contrarily if the technique you described did uncover such surreptitious microphone activity, that might be a bit more conclusive.

(Hard to disprove until you've considered all ways it could occur, and reviewed each one, and even that leaves possibilities for mistakes in method or theory)

The viewpoint is that there's no hard evidence such behavior occurs from their code, not that it couldn't be the case (still). Maybe some revelation will come out but I'm not betting on it. Fb is too smart for that and their official explanation makes sense.

For those that "believe", this lesson never gets old: [https://en.m.wikipedia.org/wiki/The_Thing_(listening_device)](https://en.m.wikipedia.org/wiki/The_Thing_\(listening_device\)) In this example, if your theory for locating a bug was based on the requirement of an electrical signal, you'd have missed such a bug entirely. Next to impossible therefore to disprove such a bug exists, if you can't consider all of the ways in which it can exist. Hope that helps you on your mission to learn reverse engineering (a skill sadly missed in the USA throw it away culture)

</comment></comment></comment></comment><comment><USER21> Without hard evidence (speech processing code, or evidence of the recordings over the wire), it's reasonable to take the official account at face value. Frankly that account is far creepier. They've built AI so smart that it knows what you're talking about.

Think about it for a minute. Fb and others have so much data on people and have trained algos so well, even they don't understand how they work so well. It's not difficult to imagine this is the case; a computer, especially one with extensive data on the lifes, behaviors and thoughts of billions of people, is far smarter and better at predicting behavior than any human could.

Scary is that it's just the beginning. I fall squarely into the alarmist camp on the AI issue. Not now, but in the long run. One can see how this scenario with the fb ad microphone spying paranoia thats actually 1 million IQ AI flexing its muscle is but the beginning of a slippery slope.

</comment><comment><USER22> Facebook may only need to recognize a few keywords. The one that companies had payed for. It wouldn't be that many. An approximate recognition is good enough. So processing and data transmission could be small.

As long as there is no uncontestable proof, the doubt must benefit Facebook.

The testimonies are not uncontestbale proofs. Considering the million people uisng the facebook app, there will always be a small set of people who will see advertisement of what they just talked about. That is statistic. Some of these, understandably chocked, may be very vocal about it.

We also know that people are payed to spread fake news and manipulate people. So I'm cautious. The truth is unknown, and the longer it takes to get uncontestable proofs, the less credible the listening thesis becomes.

Facebook can't do much appart to let it rain. Open source is the way I would go. That is one way to calm down paranoid or conspirationist people.

<comment><USER10> >As long as there is no uncontestable proof, the doubt must benefit Facebook.

they have a history of privacy violations

they have an incentive to snoop further

i see no reason to offer the benefit of the doubt to either hypothesis, as anecdotes do not constitute data

but for what it's worth, my hunch is that there's some extra snooping going on that has yet to be unearthed. might not be audio, necessarily.

<comment><USER21> Interesting, curious to hear more. What techniques are you referring to? Some re-appropriation of mobile hardware for cross sensory applications? Data sharing of some kind?

</comment></comment></comment><comment><USER23> I believe that facebook in no way can accomplish this at scale without getting caught.

Even so, i recon that your approach to test them is flawed, instead you should either of the following:

1\. Reverse engineer the applications that has access to actually capture audio from the microphone to start with, i.e. the Messenger app on android.

2\. Create a kernel module/microphone driver, which records when and which applications actually access the microphone. If the facebook apps are actually found accessing the microphone outside of a user initiated scope, one could bring the experiment to the next level and record the same audio recoding and save it for later review.

I recon 1. has already been done by several researchers, especially in relation to bug bounty programs etc. but that doesnt really mean that you should try to do it again for your own research.

</comment><comment><USER24> I think this is really something even more nefarious than background listening.

Facebook and Google are using machine learning and massive data sets about the mental worlds we inhabit when we think nobody is looking.

And these algorithms are optimizing for clicks in so many vectors of psychological need and vulnerability that it's already become incomprehensible for how they can know the things we haven't yet understood we will think about.

They know about our conversations because they know the searches of the people we talk to, and what they're thinking about. What will be on the top of their mind.

There's nothing to go looking for or debunk. It's just the next step in the data collection experiment.

I'm guessing they'll need to tone down the effectiveness of ad targeting, if they haven't already.

<comment><USER10> for those of us who are digital natives, even if we spend great effort in covering our tracks, they likely know more about us than we know about ourselves.

they use this information to employ a system of psychological levers which results in us willingly handing their proxies our money.

is it a good business practice. certainly. is it simple theft? my instinct is to say no, and instead ask:

is this new mastery of knowledge about peoples behaviors and the ability to affect other behaviors on a mass scale the most terrifying form of feudalism that mankind has known?

</comment></comment><comment><USER25> Reply All, an entertaining podcast from Gimlet Media, tackled this topic a few weeks ago [0]. They explained the myth, explained how Facebook's advertising an be explained without surreptitious listening. In the last part they called believers in the myth and tried to convince them otherwise.

[0] [https://gimletmedia.com/episode/109-facebook- spying/](https://gimletmedia.com/episode/109-facebook-spying/)

</comment><comment><USER26> Anyone with a heavy accent have these 'coincidences'? I imagine that a thick accent (Scots,etc) would be much harder to have this happen to.

</comment><comment><USER27> I personally find the alternative far creepier: that Facebook can figure you out and predict your behaviors even if it doesn't actively listen.

<comment><USER28> There certainly is a double standard. I.e.: it is creepy when FB listens to you conversations. But if they use AI to derive their knowledge about you that somehow makes it alright.

For me personally, the fact that they _can_ learn so much about me is what's creepy and reason enough to not use their services. The _how_ is merely an interesting bit of trivia.

</comment></comment><comment><USER29> is there any evidence cameras are used? I've recently been engaged in two activities in front of my phone and got scarily relevant ads that I've never seen before, and are can not be part of my graph. I am not on social networks and none of my browsing or search would be vaguely relevant.

</comment><comment><USER30> It's really amazing that people think Facebook is listening. It's like wearing a name tag and assuming someone is psychic when they call your name.

</comment><comment><USER31> This is pretty much impossible to debunk because:

A) Given Facebooks policy of A/B testing, it almost certainly isn't listening all the time.

and more importantly,

B) Now that everyone is talking about it, Facebook would have been stupid NOT to turn it off at least for now.

<comment><USER21> Would they even take a chance on this with _anyone_ knowing it'll eventually be discovered or reverse engineered? Why not take their account at face value? (We've built AI that is so smart that it can predict your conversations).

<comment><USER31> Volkswagen

<comment><USER21> Thought experiment for both scenarios:

I'd guess that my emissions cheat code blob is "safe" since no one is looking. (That guess was wrong of course).

I'd guess that my fb app code, installed on billions of phones and scrutinized by researchers the world over isn't going to be able to hide anything related to processing or transmitting speech recording surreptitiously.

<comment><USER31> Thought experiment for both scenarios:

Every significant national government has a major agency in charge of protecting the environment from harmful emissions with many paid engineers devoted to emissions testing.

None of the major national governments except Germany have an agency devoted to ensuring that devices do not en fringe on user privacy.

If you think that Volkswagen is a bad example take AstraZeneca [1]. No one had to prove that they had committed fraud by missmarketing their drugs. Much of the marketing material was publicly available. Everyone who knew the law, knew that they were breaking it.

Or perhaps you could look at Seimens, which outright bribed, using bags of cash, government officials, in order to close deals [2].

Moral of the story, corporations break laws.

If Facebook is listening to you using your phones microphone, that's not even illegal outside of Germany.

[1] [http://abcnews.go.com/Politics/Health/astrazeneca- pay-520-mi...](http://abcnews.go.com/Politics/Health/astrazeneca- pay-520-million-illegally-marketing-seroquel-schizophrenia/story?id=10488647)

[2] [http://www.nytimes.com/2008/12/16/business/worldbusiness/16s...](http://www.nytimes.com/2008/12/16/business/worldbusiness/16siemens.html)

<comment><USER21> Valid points but doesn't address the basic idea that fb knows their code is widely scrutinized. If they process or transmit audio surreptitiously, or have done so, they'd be found out. Their app is so pervasive that it's exceedingly unlikely that they'd be able to hide any such mechanism for long.

</comment></comment></comment></comment></comment></comment><comment><USER32> The people who believe it's listening would never accept even the most ironclad "proof" that it's not. This is a hallmark of conspiracy theorists.

So why bother?

<comment><USER33> I believe it's listening based on an overwhelming amount of anecdotal evidence reported all over the Internet. (Where there's smoke, there's fire.) Including by intelligent, scientifically-minded people.

At the same time, it wouldn't take much at all for me to believe otherwise: a simple blinded test where some people leave their phones in a room, researchers come and talk about some subject (absent the owners), then leave without ever interacting with the owners of the phone.

There are two ways to do the next part: The owners of the phone 1 week later could be asked if they've seen any facebook ads on (topic). A control group would have to be compared (where researchers didn't speak on the topic.)

Alternatively, the subjects of the study could be given 5 random topics when commencing the study and asked to record any ads they've seen on any of the 5 topics. The researchers could then speak on 1 of the 5 topics (differing from person to person) and a statistical analysis could be performed.

A "proof" is a statistically valid correlation between what the researchers talked about out and what the blinded subjects reported seeing ads about.

A refutation is a lack of such a correlation. Easy, and it would convince me personally.

By the way based on the anecdotal evidence I strongly expect this study to conclude "facebook is listening."

-

Note: there are a few loose ends to take care of. The researchers who are tasked with speaking on a subject are more likely to google it on their own phones. (Having been exposed to the topic), and those are in geographic vicinity. There are other similar possible mechanisms.

Perhaps the best approach is if subjects' phones are in a sound-proof vault and the researchers' speech is either fed into it via speaker/microphone, or not done so, but the researchers do not know for any specific phone whether it is able to hear them. (Making the study "double-blind", as neither the subjects nor the researchers know whether the subjects' phones have heard anything on a subject.).

<comment><AUTHOR> I don't agree with your proposed way of studying this. You're trying to study a symptom and then conclude on the cause of the symptom. That makes no sense. If you want to prove that Facebook is listening, then prove that Facebook is listening. And don't try to prove that Facebook is listening and then targeting you with ads based on what you said. There are way too many levels of indirections that can trigger false positive for a vast number of reasons you don't control at all. What you are trying to do is replicate in large- scale displays of anecdotes but with a slightly more controlled environment. That won't prove anything since it will just be anecdotes and will again not sustain rational explanation by experts of Facebook ads mechanisms.

Without getting into the ads delivery part and the anecdotes, how would you prove that Facebook is listening? How would you prove that there is a set of information taken from your speech or your audible environment transferred to Facebook.

<comment><USER33> I think you didn't read my proposed methodology carefully.

        Box     Researcher    | Owner of phone (outside room)
      [     ]~       x        |      o

The researchers speaks about some subjects, but not others. The ~ represents that in some cases the researcher's conversations are being fed into the box, and in others they are not. The box is otherwise soundproof, and inside is the phone being tested.

We can pick subjects such as:

       - #1 Adult incontinence
       - #2 Cat food
       - #3 Last-minute trip
       - #4 ..
       -    ..
       - #10

The test group is that the researchers' voices are being fed into the box. The control group is that researchers voices are NOT being fed into the box.

It is important in order to maintain double-blind environment that the researchers not hear whether they are being amplified into the box.

The results might potentially look like this:

[https://imgur.com/a/y7852](https://imgur.com/a/y7852)

Of course, I just made this up. (I imagine the subjective 1-5 scores being whether the given subject reports seeing such an advertisement, from 0 definitely not to 5 definitely yes.) I even made subject 3 unsure about topics 1 and 3 to mimic that humans are fallible. Likewise subject 2 does not really report any advertisements. (This is likely in the real world - for example subject 2 could be explicitly excluded by advertisers for some reason.)

The attached is the kind of graphs that I would _expect_ based on dozens of scientifically-minded people trying them.

If these are the two graphs that we got, and if the test and control groups were truly randomized, what other explanation could you offer?

Of course, my proposed experiment is orders of magnitude more scientific than what people are doing with their n=1, unblinded personal experiments. But theirs has some validity also.

<comment><AUTHOR> Thanks for explaining further. That would actually be an interesting experiment. Who's going to run it?

<comment><USER33> Not sure who would run it. Nobody really cares _that_ much.</comment></comment></comment></comment></comment></comment>


Python for Android - <AUTHOR> http://www.linuxjournal.com/article/10940

<comment><USER2> Article is from 2011?

Here is something more recent:

[http://python-for-android.readthedocs.org/en/latest/](http://python-for- android.readthedocs.org/en/latest/)</comment>


Answers to common questions about RethinkDB - <AUTHOR> http://www.rethinkdb.com/blog/answers-to-common-questions/

<comment><USER2> If anyone wants to play with rethink's (awesome) web UI, we setup a demo here: <http://rethinkdb.a.pogoapp.com>

We ran into a little bug w/ the ajax requests using the wrong port when run behind an nginx reverse proxy, and the team was very helpful and responsive in getting it fixed: <https://github.com/rethinkdb/rethinkdb/issues/63>

Seems like a very promising project

<comment><USER3> Thanks, but word of warning - through the Data Explorer interface it is possible to take down a core or two by passing things like 'while (1) {}' to the r.js() command

No good deed goes unpunished, etc.

<comment><USER4> There are actually really cool insidious queries you can run. There is for example a query you can run which will insert an infinite number of documents into a table!! Hats off to the first person to post it.

It's awesome that you're hosting this you should just be sure it's on a machine you're not depending on for other services.

<comment><USER5> t.forEach(t.insert(t.without("primaryKey"));

Only try this at home.

</comment></comment></comment></comment><comment><USER6> I'm almost fearful for asking this given the somewhat anti-Rails sentiment I sometimes see here, but...

Anyone know of any projects to create a Rails ODM for RethinkDB? (a la Mongoid/MongoMapper?)

Seems to me a natural fit given the (relative) popularity of MongoDB in the Rails world and the comparisons/improvements of RethinkDB over MongoDB.

<comment><USER7> To compete with MongoDB for Node crowd, you need an ORM similar to Mongoose. It seems that Node users now default to MongoDB in their stack, much like MySQL in LAMP.

For Golang, mgo <http://labix.org/mgo> is a quality implementation driver for MongoDB. Hopefully there is something similar for RethinkDB.

<comment><USER8> We're working on improving the API spec so people can write clients easily (we'll publish an RFC soon).

As far as ORMs go, we do plan to do that, but it will take a little bit of time. It shouldn't be very difficult, so we hope to get to it soon.

</comment></comment></comment><comment><USER9> I've got a question that I haven't been able to find an answer to anywhere.

What would be the best way to set up a one-to-many relationship in RethinkDB? For example, a User has a Store, a Store has Categories, and a Category has Products.

Along the same lines, is there some functionality similar to MongoDB's compound indexes?

<comment><USER8> There are two ways to set up a one-to-many relationship. The first is to use an array that holds ids. The second is to use a more traditional db approach and create a separate mapping table where each document holds ids of documents its mapping.

Use the former approach if your array will be relatively small (say, under ~2000 items). Use the latter if the number of relationships is much bigger than that.

As far as compound indexes, we don't have support for that yet, but it will happen.

<comment><USER9> Good to hear that compound indexes are forthcoming. When you do have secondary index support, will there be functionality to enforce a "unique" index, or will that have to be handled application-side?

Also, in your API documentation [1], I see there's an `append` function to add a value to an array. Is there an equivalent function to remove a value from an array?

[1] <http://www.rethinkdb.com/api/#js>

<comment><USER4> Yes, you can do arbitrary slices on an array like in python such as: array[:5]. This is done using the slice command. I believe it's overloaded in python to work with it's native slice syntax.

</comment></comment></comment></comment><comment><USER10> What has to happen before rethink is production ready?

I have to build an analytics db for commercial launch in February, it'll be a single machine cluster for the first few months. Would rethink be a risky choice?

<comment><USER8> slava@rethink here. RethinkDB is new software and still has bugs (see: <https://github.com/rethinkdb/rethinkdb/issues>) We're working very hard to iron out all reported and known issues, and improve the testing infrastructure to find new ones. There is nothing critical that's wrong with the server that we know of, but I still prefer to wait until the test infrastructure is much more comprehensive before I can comfortably recommend people to put it in production. I suspect this process will take about three months.

That being said, if you choose to build analytics on top of RethinkDB, we'll support you all the way.

<comment><USER11> I'm building exactly that (it's on postgres now, but I'm considering moving to RethinkDB when it's more stable). It's good to know you have my back.

By the way, for the benefit of the commenters here, I checked RethinkDB two days ago for <http://www.instahero.com> (the analytics app I'm building), and I ran into a bug where RethinkDB's count() would only return half my data.

The team was very responsive and fixed the bug in a few hours ( _and_ pushed the fix so I could test it), so I'm very impressed by the response time. I can't hold the bug against them, because they do say it's not production- ready.

Also, I pointed out that the DB listening to interfaces other than localhost by default was a potential security risk and that, too, was fixed in around a day. Kudos.

</comment></comment></comment><comment><USER12> "How do I install RethinkDB on other Linux flavors?"

It would be nice to mention that RethinkDB only compiles on x86-64. If you follow the instructions on the linked "building from source" page, it works fine on 32 bit machines ... until you actually run "make".

It wasn't that much time, but I wouldn't have tried if I'd known ahead of time.

Thanks for the effort!

</comment><comment><USER13> Is it production ready?

<comment><USER8> No, we're still ironing our some issues, improving the test infrastructure, etc. We'd love for you to use it in personal projects, but I wouldn't put rethink in production quite yet.

<comment><USER14> Timeline/Roadmap? That is, when will it approach being production ready?

<comment><USER8> slava@rethink here. I'm hesitant to give a timeline - we won't say the product is production ready until we know it is, and since complex software systems can have bugs lurking under the surface, it's difficult to predict how long it will take.

That being said, the way we're approaching this issue is by overhauling the test infrastructure to stress the server in as many ways as we possibly can. I suspect it will take about three months for us to feel satisfied with how extensive the test infrastructure is. Once that's in place, we'll be able to recommend rethink for production. Of course if the test infrastructure exposes hard-to-kill bugs, it will take a little longer.

</comment></comment></comment></comment><comment><USER15> I don't know if this is a common question, but it is a question I have about every data storage and retrieval engine, be it an SQL database or a NoSQL datastore:

How would you re-architect it if you knew ahead of time it would only sit on SSDs - never on spinning media?

<comment><USER4> Hi Joe Doliner engineer at RethinkDB here. RethinkDB is actually structured in exactly this way because it was originally conceived as a memcached compatible database optimized for solid state drives. Optimizing for solid state drives is a complicated matter on which we published some papers. Here's the HN comment level of detail description:

SSDs are, unlike rotational drives, inherently parallel devices. Each drive has a number of flash memory units which are capable of concurrently doing writes. To split the load evenly we divide files up into zones which we call "extents" the number of extents is configurable and varying the number of concurrent extents will give varying performance for a given drive. Normally there's a sweet spot where you have as many extents as it has independent chips. Extents are written to in a very specific manner. They are append only which means that you start at the top of the extent and fill it up with blocks of a predetermined size. The block size can be tuned to optimize performance as well although I'm not sure off the top of my head which properties of the drive determine which block size is best. Once an extent has been filled up top to bottom we stop writing to it and move on to another extent.

Garbage collection: Each block that we write in an extent is actually a version of a logical block in a btree. When blocks are changes they are rewritten and the old block is marked as garbage. This leads to extents which are filled almost entirely with garbage. When we hit a threshold we look for the extent with the most garbage copy all of the non garbage blocks to an active extent and then reclaim the extent. SSDs have their own garbage collection mechanisms that can seriously degrade the performance of the drive if when they misbehave. If we get the extent size right the drive will have a much easier time of garbage collection (I actually think the drive won't have to do anything at all for gc in many cases.</comment></comment>


Digg brings back the bury button - <AUTHOR> http://about.digg.com/blog/bury-is-back

<comment><USER2> I wonder if its too late.. It might have driven away a lot of good people. I see digg going down in popularity -

[http://www.google.com/trends?q=digg&ctab=0&geo=all&#...</a></comment>


Show HN: Nchan – a pub/sub server as an Nginx module - <AUTHOR> https://nchan.slact.net <comment><AUTHOR> This is a huge refactoring of an old project of mine -- the Nginx HTTP Push Module. I'm wondering if anyone here has used it.

Most importantly, I want feedback on the documentation. Did I overcomplicate things? Does it need more examples? Does it need more live code? Is it too long? Too short? Etc.

<comment><USER2> I love the clean client API, e.g. the use of ETags with long-polling.

In some ways it reminds me of our LiveResource protocol ([http://liveresource.org](http://liveresource.org)). It's still a work in progress, but maybe we can consolidate ideas. It'd be cool if an LR client could be pointed at an Nchan resource.

<comment><AUTHOR> Interesting, I'll read through this. Nchan code is quite modular, so it would be pretty easy to add some kind of negotiation like this. Let's talk more.

For reference, here's the old document I wrote for the long-polling protocol back in '09: [https://pushmodule.slact.net/protocol.html](https://pushmodule.slact.net/protocol.html)

</comment></comment></comment><comment><USER3> This is super interesting, I have a very similar project that we use at Discourse [https://github.com/SamSaffron/message_bus](https://github.com/SamSaffron/message_bus) clearly being an NGINX module nchan is going to be a LOT faster

That said there are few little pointers that would make integrating MessageBus with nchan a bit challenging

\- We have a concept of "reliable pub sub" [https://github.com/SamSaffron/message_bus/blob/master/lib/me...](https://github.com/SamSaffron/message_bus/blob/master/lib/message_bus/redis/reliable_pub_sub.rb) this means that if you shut your laptop and then open it stuff just magically catches up with no loss of messages or ordering. Does the redis store you have do something similar (I can not see backing lists in the redis store implementation in store.c)

\- We implement per-message security, meaning you can publish to a channel/group or channel/user and only those users get the message, I see you can do auth upfront but can per-message security seems not doable.

\- We don't bother with per-channel URLS and instead just have a single endpoint you multi-subscribe using POST params, we often subscribe to 10 channels on a request, the multiplexing seems a bit limited

\- When we subscribe to a channel due to the "reliable" nature of the store we are able to tell the server what the last id is we subscribed to and catch up from there

I definitely see us moving the moving our message bus server piece closer to the web server like nchan has, its by far the most scalable way, but its tough keeping feature parity.

<comment><AUTHOR> Nice project, and a curious featureset overlap, too...

> We have a concept of "reliable pub sub" [...] Does the redis store you have > do something similar (I can not see backing lists in the redis store > implementation in store.c)

Dig a little deeper... [https://github.com/slact/nchan/blob/master/src/store/redis/s...](https://github.com/slact/nchan/blob/master/src/store/redis/scripts/get_message.lua) I used lua scripts for all the fancy redis logic, that's where you'll find the backing list accesses. Messages are stored as hashes, referenced by id in lists, along with some other channel metadata. So a longpoll or EventSource client knows its last message id, and can request the next avaliable message as long as said message has not yet expired. Websocket clients don't have this information, and I'm not yet sure how to relay it with each message while remaining content-agnostic. Basically, regardless of the protocol, you can send a If-Modified-Since + If-None-Match or Last-Event-ID headers and it will resume from that position in the message queue for the given channel.

> I see you can do auth upfront but can per-message security seems not doable

Per-message access will definitely not be implemented. You could, however, do this client-side by, say, encrypting the messages and sharing keys with authorized subscribers. That's kind of roundabout though.

> We don't bother with per-channel URLS [...], we often subscribe to 10 > channels on a request, the multiplexing seems a bit limited

The main use-case I had in mind for multiplexing is that of a single channel per user, and some shared broadcast channel. It's currently limited to 4 max because I wanted to get this code out the door. Unlimited multiplexing will be supported in the future, and you could trivially rebuild the module to support up to 16 right now (At the cost of some memory per message per subscriber per channel overhead).

> When we subscribe to a channel due to the "reliable" nature of the store we > are able to tell the server what the last id is we subscribed to and catch > up from there

Yep, Nchan does that too. (except for Websocket, and hopefully I'll find a workaround)

How does that work for feature parity?

<comment><USER3> nice! I initially stayed away from lua due so I could support earlier redises, but these days I would totally take that dependency on to simplify the code.

regarding that implementation, one diff I am spotting is that I also have a concept of global message id / global channel, this allows us to subscribe to a single spot and distribute from there (which keeps thread counts down and is particularly useful for server -> server comms.)

A lot of parity with our projects :)

Regarding web sockets, I decided against supporting them (initial implementations did) the issue is that web sockets are 100% flaky on HTTP and just add tons of unneeded complexity, in advent of HTTP/2 in NGINX they would be a net loss imo cause you would be wasting a connection.

<comment><AUTHOR> > global message id / global channel Yeah, I don't have global ids. every > message is bound to the channel it was published to. But I do understand > that for your use case, (user + arbitrary list of groups), you'd need a good > deal more than 4 channel multiplexing. It's a pretty strong use case and > I'll see what I can do in the next month.

Of course, I can be incentivized to work faster with a generous donation :)

> Regarding web sockets [...]

All the cool kids were talking about it, so I thought I might as well support them, too.

<comment><USER4> >All the cool kids were talking about it, so I thought I might as well support them, too.

I agree with Sam Saffron (thanks Sam for al your githubcode) about some perplexity using websockets as a panacea nowadays.

Nevertheless, I really appreciated Nchan structured approach, open to different available protocols (poll, SSE, websockets) :)

</comment></comment></comment></comment></comment><comment><USER5> Does Nchan broadcast messages that may have been missed by a client that was temporarily offline? When web client's navigate from page-to-page or enter sleep mode, client's will miss messages during the offline delta. Ideally, there would be a way to "catch-up" a client or to tell if a client is permanently out-of-sync because it is beyond a message history window.

<comment><AUTHOR> Yes. All messages are buffered for a configurable length of time. Longpoll and EventSource clients receive the last message id with each message, and if interrupted can be resumed from there provided the message has not timed out. I don't yet have a way of transferring the last-received message id for websocket clients, but if it is known it can be set during the ws handshake.

</comment></comment><comment><USER6> I'm using Nginx Push Stream with NodeJS for a high-scale chat system (Soon to be released, completely Open-Source). The dependency on Nginx always bothers me. How hard do you think it would be to do a system like yours but completely standalone ? Then we would be able to integrate it to other languages via plugins (NodeJS, Python, etc).

<comment><AUTHOR> Nchan is about 12K lines of C, I'd say 2-5K of that is dealing with Nginx guts. To get rid of Nginx entirely, you'd need to add an event loop, forking and multiprocess management, config parsing and reloading, and shared memory allocation code. That's not a simple task, but it's certainly possible. The reason I built this on top of Nginx is precisely because I didn't want to handle those other things. Besides, nginx these days is a hulking scalable monster. What's the bother?

If you really don't want an nginx dependency, I'd say you're better off rolling your own pubsub server in Node.

<comment><USER6> Okay, thanks for the information. The problem with doing the pubsub in NodeJS entirely is the way NodeJS handle connections. Each is separated and is accompanied by a big overhead from NodeJS. What would be great is a way to interact with the pubsub server not by config but with an API. This would allows, for example, the execution of middlewares when a user publishes a message (to filter them or something else). Right now, I'm using two websockets, one to Nginx PushStream only to receive messages and another to the NodeJS server to publish messages. The NodeJS server is used to parse the messages, format them, authenticate the user and apply the middlewares before publishing the message to Redis. Then, each NodeJS get the message from Redis and POST it to Nginx. The problem here is that there is two sockets for each user and the complexity involved with the communication between Nginx and NodeJS. That's why a really performant standalone websocket engine with an extensive API would be awesome.

<comment><AUTHOR> > the execution of middlewares when a user publishes a message (to filter them > or something else)

You can do that with nchan: [https://nchan.slact.net/details#authenticate- with-nchan_auth...](https://nchan.slact.net/details#authenticate-with- nchan_authorize_request)

> Right now, I'm using two websockets, one to Nginx PushStream only to receive > messages and another to the NodeJS server to publish messages.

You can also multiplex several websockets into one for the client.

I can't offer you a standalone server, but I can offer some pretty fancy features : )

<comment><USER6> I saw this feature, but I think there is limitation preventing me to use it, tell me if I'm wrong ;) \- I cannot use this to make a call each time a message is published on a pubsub websocket \- I cannot modify the message sent by the user (to add user information for example)

Also, what do you mean by multiplexing websockets ?

<comment><AUTHOR> That's correct, that feature is for authentication only. I may add a feature to replace the message with the back end response.

By multiplexing I mean that a single websocket (or any other) subscriber can subscribe to multiple channels.

</comment></comment></comment></comment></comment></comment><comment><USER7> Is this different from the other module nginx push stream which offers websockets, long polling etc

<comment><AUTHOR> Yes, this is a different project, although they are related. Push Stream is a fork of my Nginx HTTP Push Module, so they both descend from the same original codebase. Push Stream uses a blocking concurrency model, whereas Nhan is completely non-blocking. In theory, this means Nchan should scale better. In practice, I haven't benchmarked it heavily enough yet to see a divergence.

Besides that, nchan and Push Stream offer different feature sets. For example, Nchan has horizontal scaling and persistence through redis, whereas push stream has customizable message transforms. There are other differences as well, but that would take a whole article to elaborate. I should probably write it soon.

</comment></comment><comment><USER8> The "client-less" approach would be particularly nice for use with IoT devices which don't have enough CPU/memory to run a beefy pub/sub client (which is typical of other solutions). So that's nice.

Is there a way to perform access control on the backend? E.g. Is there a way to prevent a specific user from subscribing to a specific channel (if they are not allowed)? Or is this specifically designed to deal only with public channels (that anyone can publish/subscribe to)?

<comment><AUTHOR> Yes, backend-authenticated access control is possible. See [https://nchan.slact.net/details#authenticate-with- nchan_auth...](https://nchan.slact.net/details#authenticate-with- nchan_authorize_request)

</comment></comment><comment><USER9> Wow, excellent! I've been looking for lightweight websockets pubsub and had to create something simple in Node to achieve it but this would've sufficed.

I can't wait to give it a try.

</comment><comment><USER10> Great project! Is there any concept of ack/nack a message? Let's say the subscriber get a message and failed before processing it. Does the message go back to the queue?

<comment><AUTHOR> No, ack/nack would need to be implemented in the client or the application.

However, messages do not disappear from the queue when received. All subscriber requests are idempotent, and can be repeated so long as the message queue is storing the message (which is a configurable parameter). So if a subscriber failed before processing it, it's free to request the same message again.

</comment></comment><comment><USER11> Interesting project. I've up till now used Twisted or Tornado (actually swampdragon.net). My choice would be dependent on scalability and performance.

<comment><AUTHOR> I consider those two and socket.io my main competition. Nchan is built to scale, but of course you'd need some numbers to back that up. I plan on doing benchmarks once I iron out the documentation, although I realize it would be a great selling point to have the numbers ready right away.

</comment></comment><comment><USER12> How does this compare to MQTT ?

<comment><AUTHOR> I'm not familiar with MQTT, I've just glanced over the spec right now.

Nchan is basically a message broker with channels, optimized for message broadcast.

MQTT is a TCP-level protocol, whereas all the currently implemented subscriber clients for Nchan are HTTP-level (Longpoll, EventSource and Websocket, which begins with an HTTP request). MQTT subscribers and publishers _could_ be implemented in nchan, but I haven't yet written any raw-TCP connection negotiation code, so I don't know how hard it would be. Aside from that, the subscriber code is very modular and adding another protocol like MQTT would be straightforward.

<comment><USER12> I see. Thank you for this, I'll give it a shot and see how a simple client compares to an MQTT client.

If I get a good performance on a C/C++ client then this could be a viable option for push notification in the IoT domain.

<comment><USER4> >this could be a viable option for push notification in the IoT domain.

Yes! :)

</comment></comment></comment></comment><comment><USER13> This is wonderful. I hope this module gets added to openresty.

</comment><comment><USER14> Is the description just a rather roundabout way of saying it can be used as an anonymous messageboard? The name certainly evokes that.

<comment><AUTHOR> Well, it would be very easy to make a realtime 4chan-like thing with Nchan, but it's far from the only use case. It's a general-purpose server and pubsub proxy.

The name is a play on nginx and channels. I got tired of saying "nginx http push module" all the time and renamed it.</comment></comment>


Born to Be Conned - <AUTHOR> http://www.nytimes.com/2015/12/06/opinion/sunday/born-to-be-conned.html <comment><USER2> I liked how this article started out talking about interesting anecdotes of people being conned and very gracefully transitioned to the longest running cons in the world (organized religion).

<comment><USER2> Now that I think of it - I think this article itself is a great example of a short con.

You start reading it, convinced that it's an interesting story about how easy we humans are convinced of falsehood by a good tale told by a very small portion of the population who are excellent liars and exploitative criminals.

All of a sudden, the topic is deftly repointed to the subject of religion, something that the current global majority does not believe is a lie.

And I didn't even realize it until about 30 mins after I read it!

Very well done.

<comment><USER3> _All of a sudden, the topic is deftly repointed to the subject of religion, something that the current global majority does not believe is a lie._

They kind of do, though. If you take a religious person, they will (unless they're some kind of polyglot religious type) tell you that the vast majority of all the religions that have ever existed were a lie. 99% of them. More than that. They'll tell you that very nearly every religion, ever, is a lie.

<comment><USER4> "Incorrect", perhaps. The number that would say "a lie" about nearly every religion, ever, is considerably smaller.

</comment></comment></comment></comment><comment><USER5> Is it just me or does the physicist flying to meet the south american model fall into the "can't con an honest man" bracket that the author thinks often doesn't apply? He must have noticed that attractive models in his own country weren't lining up to date him, so what did he think was going on here?

The art dealer story had a similar ring, and they mention Bernie Madoff in passing, someone who was beating the market for years, which apparently most clients assumed meant he had access to info to use for insider trading.

<comment><USER6> I was thinking the same thing about all of them except the girl who's boyfriend fabricated his life story for her.

</comment></comment><comment><USER7> This article about the Dove ad is still a brilliant more direct discussion on how people are broken: [http://thelastpsychiatrist.com/2013/05/dove.html](http://thelastpsychiatrist.com/2013/05/dove.html)

<comment><USER8> TLP is brilliant as usual, but seems a bit depressed to me. The message "stare hard at the painful reality instead of comforting lies" might not be good advice for many people, especially us geeky folks who are already biased toward taking ugly truths too seriously.

</comment></comment><comment><USER9> _"... as more of the world is explained — and ends up being not so divine after all ..."_

I don't understand this sweeping statement by the author (who seems between the lines to be struggling with her own issues of faith and belief, and hence had to write a book about how gullible humans are).

Is she saying that something, once explained, can no longer be divine?

<comment><USER10> I think you're putting words in her mouth, so to speak. That paragraph begins by repeating a statement about God being found in the cracks between knowledge. I know I've read this elsewhere, it's not a new idea. The rest of the paragraph just restates this in a way that I think is very fair.

My direct answer: yes. IMO divinity is just magic backing a particular narrative. As we discover and accept alternative explanations for why things are the way they are, that magic disappears and the narrative loses power.

<comment><USER11> > God being found in the cracks between knowledge

See here:

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

</comment></comment></comment><comment><USER12> This article would be far more interesting if it showed ways of picking out inconsistencies even when embroiled in blind belief.

</comment><comment><USER13> Does the article explain what the play on Joan was? I can't find it.

My guess is get close enough to find the personal details necessary for identity theft.

Long cons like that fascinate me. Such a large investment, especially of time, with real risk!

<comment><USER14> Maybe nothing more than the pleasure and value of her company (and share her wealth), just someone who wanted a mate and bluffed about his accomplishments.

The same con that spouses around the world play.

</comment></comment><comment><USER15> As the connectedness of the world increases, we are all going to have to improve our epistemological immune systems.

</comment><comment><USER16> Ah, the oldest profession in the world: Fleecing Rubes.

<comment><USER12> Yes, but it's saying we are all rubes.

</comment></comment><comment><USER17> The author is "Maria Konnikova"...seriously? ...hmmmm...</comment>


How the Internet killed porn - <AUTHOR> http://www.guardian.co.uk/culture/2012/jun/05/how-internet-killed-porn

<comment><USER2> Makes you appreciate the industry a little bit more. Surprising how much performer fees have fallen.</comment>


100,000 Chinese are full-time professional video game gold-farmers - <AUTHOR> http://www.nytimes.com/2005/12/09/technology/09gaming.html?ex=1291784400&en=a723d0f8592dff2e&ei=5090&partner=rssuserland&emc=rss

<comment><USER2> If people are willing to pay for a higher level avatar, etc, I wonder why Blizzard doesn't just allow one to purchase that directly from them. Virtual worlds are one place where actually putting time in to do "work" is only required if the owners of the world decide to require it.

<comment><USER3> There seem to be two MMO models, the subscription model and the subscription- free model where you pay for better gear. I don't know if there are any hybrid games (I don't play any MMOs myself) but I could imagine that once the premium practice was legitimised, people would get upset about having to pay for the subscription.

<comment><USER4> You can sell time cards for in game cash in eve online. You can also trade charters between accounts in eve.

At the same time there seems to be a lot of gold farmers in the game.

I think everquest opened a server where you could buy cash but there are few high end items you can get by spending gold in that game.

</comment></comment></comment><comment><USER5> This trend has been going on for some time:

[http://terranova.blogs.com/terra_nova/2005/12/nytimes_tracks...](http://terranova.blogs.com/terra_nova/2005/12/nytimes_tracks_.html)

What I think is really interesting about WoW is that unlike practically every other MMORPG, the number of subscribers continues to rise after four years on the market. The usual pattern is to peak after a year or two, and then gradually fade:

<http://www.mmogchart.com/Chart1.html>

I wonder about the role of expansion packs in this phenomenon, and whether other types of gaming or software products could follow a similar model, instead of complete product replacements to new versions.

<comment><USER3> Interesting graph. (although someone needs to be introduced to the concept of a logarithmic scale)

I found it particularly intriguing that (as far as I can make out) at no point in time did Everquest 2 have more subscribers than Everquest, and the same is true for Lineage 2 and Lineage. I wonder if that's one of the reasons Blizzard are continually upgrading the existing game rather than releasing a replacement?

As for other software: well, I think a lot of subscription-based and/or web- based software already does this. You don't choose to switch to GMail 2.0, it's just a steady trickle of new stuff.

Conventional games on the other hand are very hit-driven - they don't peak after a year or two but within the first few weeks, after which they fall off more or less exponentially. They do release expansions for many games of course, although I think it depends heavily on the game how well that sells. (the famous extreme example is of course Railroad Tycoon 2, where the expansion sold more copies than the base game due to piracy)

</comment></comment><comment><USER6> That's a staggering number; it's larger than the current British Army.</comment>


US sales of guns and ammunition soar amid coronavirus panic buying - <AUTHOR> https://www.theguardian.com/world/2020/mar/16/us-sales-guns-ammunition-soar-amid-coronavirus-panic-buying <comment><USER2> A lot of media trying to push this as hillbillies/rednecks wanting to defend their hoard of toilet paper are short-sighted.

Panic & fear cause people to make unpredictable poor decisions, and you never know if that could affect you and your family. In the USA, you have a right to defend yourself and these people are just choosing to do that. Please don't demonize them for just wanting to protect themselves and their families.

Be safe and watch out for each other.

<comment><USER3> Having a gun in your home also increase the probability that one of your kids can find it and kill another of your kids by accident. It is a tradeoff.

<comment><USER4> Respect for firearms is an extremely important skill to teach a child. Having grown up hunting, this was taught to me at a very young age. But more kids die from drowning in pools than from accidental firearm discharges, and it's also important to teach your child water safety and swimming skills.

<comment><USER3> I agree. Swimming pools are more dangerous than the people realize. Never left the children unattended nearby a swimming pool.

</comment></comment></comment></comment><comment><USER5> Personally I've been wanting to do a bulk ammo buy for a while, and realized there was going to be a run so I dumped 1000 bucks into some ammo for all the calibers I own.

I'm also in the process of building an AR-10, and have slowly been accumulating parts. Decided to pull the trigger on some of the more expensive parts this week because I caught some good deals.

It's not all panic buying.

<comment><USER6> I was going to put an order in cause I've got a couple shoots coming up. Everything was in stock Friday. I went to buy today and everything but some of the more obscure cartridges are sold out. It is pretty crazy.

</comment></comment><comment><USER7> As a non-American, I'm imagining this scene playing out with armed people.

[https://thenewdaily.com.au/news/national/2020/03/07/coronavi...](https://thenewdaily.com.au/news/national/2020/03/07/coronavirus- toilet-paper-fight/)

Far from making fun of Americans, I am scared for them. This crisis has already proven how irrational people can be, and rapidly we revert to basic tribalism, giving in to base instincts. Adding (even more) guns to this mix is a bad sign. But in an environment where trust in authority has been systematically destroyed, it is, a sadly understandable response.

Stay safe, and remember that most of the people you might be defending yourselves from are probably just as desperate (if not more so) than you.

<comment><USER8> you're afraid people will murder each other in times of strife?

if you really think this will devolve into violence, then you aught to understand what the firearms are being bought for. it's not to go mad max on somebody.

</comment></comment><comment><USER9> Trust in the system is at an all-time low. At Amherst College, the administration decided shortly before Spring Break that students should not return after the break in order not to bring back coronavirus to campus and spread it there. There would be accommodations when necessary.

There was a sit-in to protest against the very sensible decision. One would think that at the second-best college in the nation the administration would be aware that some students may have difficulties coming up with emergency funds for travel, that there may be travel bans or that some students might not wish to return to unstable living conditions at home. But the students did not trust the system to work for them.

Some stage sit-ins, others buy firearms.

</comment><comment><AUTHOR> In a stressed society with low friction access to fierams, buying an assault rifle is just working your way towards Nash equilibrium.

Terrifying.

<comment><USER10> Do you mean an _actual_ assault rifle, or just a "scary black gun" that is functionally equivalent to any other modern semi-automatic hunting rifle (and shoots lower powered rounds than many common hunting rifles)?

If it's the former, there's nothing low-friction about it. You have to fill out more forms, pay more money, get more background checks, etc. etc., yadda yadda, and you can't buy any such weapon manufactured after 1986.

[https://www.washingtonexaminer.com/its-still-legal-to- own-a-...](https://www.washingtonexaminer.com/its-still-legal-to-own-a- machine-gun-its-also-extremely-difficult-and-especially-expensive)

<comment><AUTHOR> I meant an actual Nash equilibrium.

My experience of firearms is limited to three years in the (not US) military so I'll deffer to you on comparative merits of semi automatic vs hunting rifles available to civilians on the US market.

</comment></comment></comment><comment><USER11> Post your loadouts HN

Primary : MK18 BLOCK 3 URGI ([https://i.redd.it/tgnpp2xi82q11.png](https://i.redd.it/tgnpp2xi82q11.png)) Secondary: Roland Special

</comment><comment><USER12> During that time in Canada we buy toilet paper...

</comment><comment><USER13> The USA is absurd.

</comment><comment><USER14> Between the economy, the oil price war, the politicization of politics, and most pressingly the virus, 2019ncov is proving to be the potential trigger for wide scale geopolitical change and possibly insecurity. States are going to go into quarantine one by one with little to no coordination. Governments and law agencies will be commandeering emergency powers. We are sitting on a major pressure point and it's impossible to predict the outcome, but there is a high likelihood of political instability and/or violence, even within America.

If the economy doesn't recover soon, people are going to grow increasingly hungry and desperate without radical federal measures. It is prudent to be prepared to defend yourself now because this is shaping up to be the kind of scenario where you really cannot rely on first responders to protect you.

Edit: I meant "polarization of politics" but autocorrect may be hinting at something profound...

<comment><USER9> _politicization of politics_

That's a good one, it reveals an unexpected, deep truth.</comment></comment>


What Kubernetes users should know about the rkt container engine - <AUTHOR> https://coreos.com/blog/rkt-and-kubernetes.html <comment><USER2> If you want to just try the integration today try minikube [https://github.com/kubernetes/minikube#using-rkt- container-e...](https://github.com/kubernetes/minikube#using-rkt-container- engine)

This integration is about 90% complete and will completed going into 2017.

</comment><comment><USER3> It's a shame AppC is going away[0]. OCI is pretty much just a formalization of what Docker already does, so we're stuck with (IMO) implementation details like layers as part of the core image spec.

0\. [https://github.com/appc/spec](https://github.com/appc/spec)

<comment><USER4> AppC has layers[0]. In fact, an ACI is just a layer.

While layers are codified into the OCI specification, the manifest system is flexible and allows for future extension. The main goal of OCI is to provide a specification for what is already widely deployed without introducing too many new concepts.

[0]: [https://github.com/appc/spec/blob/master/spec/aci.md#image-m...](https://github.com/appc/spec/blob/master/spec/aci.md#image- manifest)

Disclosure: OCI Maintainer, Docker Employee

</comment></comment><comment><USER5> It's really cool to see this stuff emerging, and the CoreOS folks put out some good info at kubecon. We're currently running k8s on the docker engine like probably just about everyone, but for the same reasons as just about everyone we're interested in seeing the development of standard runtimes for containers and orchestration. Having said that, I'm not sure I'm all in on this idea of "pod sandboxes" as the environment in which application components are grouped. I may just need to wrap my head around it, but after getting comfortable with the cluster as the sandbox for applications composed of pods I guess I haven't grasped the utility of the additional abstraction.

<comment><USER2> The pod sandbox is the abstraction that replaces the "pause" container that is used to keep namespaces open in every Kubernetes pod today.

Some techinical explanation here: [https://groups.google.com/forum/#!topic/kubernetes- users/jVj...](https://groups.google.com/forum/#!topic/kubernetes- users/jVjv0QK4b_o)

So,a normal Kubernetes user will never know about rkt pod sandboxes and Kubernetes pods will just work as expected. Only you won't have all of these weird "pause" containers everywhere.

<comment><USER6> +1 Death to `pause` (and it's largely my fault in the first place)

</comment></comment></comment><comment><USER7> I'm stating to really get into containers. They make sense and can keep sane environments; keeping you away from dependency hell (at the expense of potential security issues if you don't have tools that regularly scan and tell you when packages within containers have security issues).

Unfortunately, the orchestration formats are all over the place. Kubernetes, DC/OS and Docker-compose all have their own json schema. DC/OS doesn't even support docker container volumes. Rancher can take docker-compose, and it looks like it can deploy those apps on K8s/DCOS, however I haven't messed with it enough to see if that actually works.

Rkt just adds even another container format. What once seemed like a nice one- stop isolated application that you could run anywhere is becoming more complicated and more tightly coupled to the underlying container engine and orchestration system you chose to use.

<comment><USER8> DC/OS most certainly supports Docker volumes. What made you think it doesn't?

<comment><USER8> Or perhaps you're referring to the data volume containers. Regardless, you can pass arbitrary arguments to the Docker daemon if you choose.

</comment></comment></comment><comment><USER9> using rkt on platforms other than coreos is hard... or maybe harder than docker. a lot of us first try these things on our desktop and then attempt to put them in production.

for example, the mucking about SELinux on fedora is a recipe for disaster.

my request would be to package it better. its not a bad idea to use the new snap package (like docker).

and a page with docker cmd <-> rkt cmd would be very welcome!

</comment><comment><USER10> The article states:

"In parallel to the image format, OCI is developing the so-called runtime-spec for describing the runtime execution environment that container engines should provide."

I thought the run-time spec was formalized and that we were waiting on the OCI image format to be standardized. Is that not the case? This was from a recent conversation I had with someone at CoreOS.

<comment><USER2> The OCI runtime and image specs are currently 1.0.0-rc3. Hoping they both hit 1.0.0 final in early 2017.

<comment><USER10> Ah OK, thank you. Yes lets hope it arrives soon.

</comment></comment></comment><comment><USER11> Does anyone use rkt?

<comment><USER12> Rkt really is missing good on-boarding / Getting Started instructions. I don't have time to figure out all the details and I really want to know how to do the following things:

1\. Create Dockerfile like equivalents for Rkt images

2\. Share and publish Rkt images.

3\. Consume Rkt images in a Kube cluster that already supports Docker on AWS.

<comment><USER13> I gave it a try. The docs are good, but they could definitely be better [1]. I found a couple doc errors and got PRs merged quickly.

[1] [https://github.com/coreos/rkt/blob/master/Documentation/tryi...](https://github.com/coreos/rkt/blob/master/Documentation/trying- out-rkt.md#building-an-app-container-image)

<comment><USER12> Thanks!

</comment></comment></comment></comment><comment><USER14> No mention of Kontena.io ? Too new or too European?</comment>


What Happens When You Infiltrate the Republican Party? - <AUTHOR> http://www.huffingtonpost.com/steven-brykman/infiltrate-the-republican-party_b_2742532.html

<comment><USER2> What happens when a rag's endless political pandering infiltrates HN</comment>