Show HN: Open-sourcing my rejected iOS app, In-Stock - <AUTHOR> http://alpblog.heroku.com/in-stock/ <comment><USER2> This is why you should read the App review guidelines [1] before you start. It's right there in black and white:

 _12.1 Apps that scrape any information from Apple sites (for example from apple.com, iTunes Store, App Store, iTunes Connect, Apple Developer Programs, etc.) or create rankings using content from Apple sites and services will be rejected_

[1] [https://developer.apple.com/appstore/guidelines.html](https://developer.apple.com/appstore/guidelines.html)

</comment><comment><USER3> Nice! I've been thinking, if there were more open-source apps for iOS, then the developer account could become the new (albeit pricey) jailbreak.

Maybe someone could even build a nice installer or wrapper around Xcode so that non-technical people can install such apps (and pretend to the phone they were developing them).

(Disclaimer: I'm more familiar with Android than with iOS development, don't know for sure this would work)

<comment><USER4> Unfortunately you still aren't able to use your own hardware how you'd like on iOS, even with a developer account. Certain private APIs (like the VPN one)[1] require an "Entitlements" file linked to a provisioning profile that is difficult or impossible to forge.

1\. [https://github.com/chrisballinger/openvpn-server- ios#openvpn...](https://github.com/chrisballinger/openvpn-server-ios#openvpn- server-ios)

</comment></comment><comment><USER5> "I'm a software engineer @ Microsoft's cloud computing service, Windows Azure."

Props to Ahmet for being open about building products and using tools from competitors rather than denying they exist.

<comment><USER2> …iMessage hosts content on Azure.

<comment><USER5> True. Apple uses a number of cloud services including Azure, AWS, etc.

<comment><USER6> I've heard Apple using Azure but never heard of their use of AWS. How come this isn't advertised on AWS's or Azure's related page(s)[1]?

[1] Case study pages can be an example for "related page(s)" for AWS: [http://aws.amazon.com/solutions/case- studies/](http://aws.amazon.com/solutions/case-studies/) for Azure: [http://www.windowsazure.com/en-us/overview/case- studies/arch...](http://www.windowsazure.com/en-us/overview/case- studies/archive/)

But "for some reason" I can't think Apple sharing their experience with a platform online. It's not in their DNA, I think.

<comment><USER2> Because Apple's agreements with these companies will include a clause stating that they cannot publicly acknowledge they supply Apple.

</comment></comment></comment></comment></comment><comment><USER7> I feel like Apple's rejection of this app / DMCA shutdown of apple-tracker supports its brilliantly annoying marketing - scarcity creates mystery. The fact that you might not be able to get it makes you want it more; not knowing what iPhones they have in stock adds a weird level of excitement to the process of purchasing one.

Apple could make this app in a second, but they don't because they want you to wonder, they want you to fret, and they want to make it that much more satisfying when you actually get it.

</comment><comment><USER8> This is why HN should also display subdomains in submissions. This is a blog of a random guy, which redirects to another domain, but gets most of the attention because of heroku.com at the end. There are many apps being rejected by Apple each day because of violating their ToS, and I fail to see why this story would be more relevant than others.

<comment><USER6> It's a bit different rejection story from the most (but certainly not different from all), that difference being Ahmet open-sourced his app, rather then just whining about rejection and burying the code.

And, IMHO, if it wasn't relevant to the community, they wouldn't up-voted it to the homepage.

Also, I agree HN should show subdomains for this kind[1] of sites.

[1] This kind being websites offering subdomains for user-genarated content that is not related to the company which owns the domain.

</comment></comment><comment><USER9> Have you tried writing your own very thin wrapper for scraping Apple instead of doing it directly inside of the actual application?

I like the app... It's clean and simple. I had this problem the other night. I wanted to see stock of phones and unless you begin the process of upgrading your line, you can't do that on mobile.

Anyway, seems like there might be a creative solution here if you run your own lightweight proxy-like API so that on the surface it appears like you're not scraping Apple. It also opens the door for repeating the experience of your native app as a mobile friendly website.

<comment><AUTHOR> They asked me how I find out exactly how many iPhones left in a Store and I tell them I am using their AJAX call on mobile clients.

Even though I create a proxy, they had to validate how accurate my data is and how I get it. So building a proxy won't help either I suppose. See other comments here regarding a DCMA takedown happened yesterday for a website launched very recently doing the same thing. This is just scary.

</comment></comment><comment><USER10> Well, if you think there's a demand for it just do a mobile html version. It's not a super complicated app to implement with html.

<comment><AUTHOR> Not at all, but I won't be doing it I guess. If you'd like to pick this up, logic is out there. It has a bit of manual work for getting SKU numbers of products but I'm pretty sure it is doable.

</comment></comment><comment><USER6> Although it's not much of a use for me since I'm not in the U.S., looks nice, polished, dead-simple. Ability to open store locations in Google Maps (in addition to stock Maps.app) and remembering last chosen items are nice features too. Too bad Apple is not very open to this kind of things.

By the way, does Apple's official Apple Store application has this feature?

</comment><comment><USER11> On a related note, Apple also sent a DMCA take down notice to a site which did something similar for iPhone 5S availability: [https://news.ycombinator.com/item?id=6680716](https://news.ycombinator.com/item?id=6680716)

Site in question: [http://www.apple-tracker.com](http://www.apple-tracker.com)

<comment><AUTHOR> Wow, that's big. Thanks for pointing that out. I didn't know what could be the potential consequences of releasing this app. Apple really does not care if you are making things easier for people as well as them.

</comment></comment><comment><USER12> Nice app. It reminds me of [http://www.refurb.me](http://www.refurb.me), which is to track the stock of refurbished Apple devices.</comment>


WebSocket Protocol Updated - <AUTHOR> http://blog.chromium.org/2010/06/websocket-protocol-updated.html <comment><USER2> Note: this means that with the new version of Chromium, none of the web applications using Web Sockets will work. The connection will fail with an error about a protocol mismatch.

<comment><USER3> It's pretty poor they couldn't work out how to make things backward compatible.

Oh well, another job for me to do then...

I just love reading through a billion pages of a spec to find the actual data I need which could have been written in a single page spec. bah.

Would it be so hard for them to put the 'answer' somewhere? eg "To make your server work again, change "X" to "Y" in the headers".

I'll say it again, the spec is simply insane.

      18.  Let /number_1/ be a random integer from 0 to /max_1/ inclusive.

            Let /number_2/ be a random integer from 0 to /max_2/ inclusive.

            EXAMPLE: For example, 777,007,543 and 114,997,259.

       19.  Let /product_1/ be the result of multiplying /number_1/ and
            /spaces_1/ together.

            Let /product_2/ be the result of multiplying /number_2/ and
            /spaces_2/ together.

            EXAMPLE: Continuing the example, 3,885,037,715 and
            1,034,975,331.

<comment><USER4> Backward compatibility to what? They are in progress of creating the first version now.

<comment><USER3> Websockets have been in Chrome and in use for 6 months+.

<http://news.ycombinator.com/item?id=989680>

We have thousands of users using WebSocket every day. So this is kind of a pain in the neck.

<comment> mike-cardwell This is what you get when you use an unfinished protocol which everybody knows is subject to change. Guess what, it might change again... They're still researching what is the best way to do this. You should be happy they're making improvements to the protocol you're using.

If they say, "This is the finished product and there will be no further incompatible changes," and _then_ make a change which breaks your app. Then you have a right to complain.

<comment><USER3> I'm looking through the spec now. There don't seem to be any improvements. Just incompatible changes made in bizarre ways.

I'll post a summary of the changes tomorrow.

These sort of things often seem like they're massively over engineered. You could figure out the best way to do websockets in an afternoon without too much fuss.

Nothing is ever 'finished'. It's just a pain to break backward compatibility that's all.

<comment><USER5> _These sort of things often seem like they're massively over engineered._

Until you're the edge case who gets pissed off because they didn't make it flexible enough, or the boilerplate is arcane and doesn't really make sense with much of the normal use.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Mibbit said...

Sorry but the spec for this is just ridiculous. It's insane. It contains the code to parse HTTP headers, translated into _english_. You could easily condense this spec down to a couple of pages, and it'd actually be usable.

Once again, sorry, but this is just ridiculous.

June 3, 2010 10:31 AM

</comment><comment><USER7> Is it possible to write a server which supports both versions?

<comment><USER8> Based on their description, it sounds like a bad idea even if it is possible. Why would you want a fundamentally insecure protocol on your website?

This is "draft" for a reason, and note this is not a final protocol, it's another draft. That's for a reason too. Don't expect your -76 server to last forever with no changes either.

<comment><USER3> You shouldn't rely on any protocol like this being 'secure'. You should have other security in other places. So I don't think that's a valid reason really.

It's possible to support both, and that's what I'll personally be doing with my own web server.

The changes I've seen don't add any obvious extra security as such, just make it a little more difficult.

edit: Please give clear references when you say "Fundamentally insecure protocol". That's pretty much totally unfounded. What type of security are you talking about?

<comment><USER8> "Please give clear references when you say "Fundamentally insecure protocol". That's pretty much totally unfounded. What type of security are you talking about?"

Directly from the article: "introduces nonce-based challenge-response to protect from cross protocol attacks." In my experience, when people identify a possible security attack it's usually correct. (The solution can be another matter, but I'm not looking at this enough to have even an uninformed position.) The problem the sort of people working out a protocol like this have is missing ones that are possible, not pointing out ones that don't exist.

If you're comfortable with unnecessarily insecure lower layers, more power to you. Don't expect plaudits from me. Or expect me to be taking security advice from you after casually disregarding things like "security in depth".

<comment><USER3> The original version of the protocol was already pretty strict. It required exact responses, played in exactly the correct order in order for a connection to be established.

All the new version does, is send over some obscure challenge data (generate a random number, then insert random characters into it????). Then it expects a response from the server with the value md5(challenge).

That does indeed get rid of a class of cross protocol attacks, but it's a ridiculous edge case as far as I can see.

Previously you may have been able to find some server (non HTTP), that you could connect to, somehow get it to respond with the correct HTTP headers in exactly the right order, and continue. Then exploit it - send spam email, etc etc

That's pretty unlikely.

Now, you'd have to get that server to respond with the md5 response, which is fairly impossible.

BUT. The security here is in Browser->"Some non HTTP server being tricked" - eg something I don't care about too much. Make your "non HTTP server" more secure. For example see the recent exploit against freenode earlier this year, where they allowed connections from an automated HTTP POST in the Firefox browser - the ircd just ignored any HTTP stuff and happily connected users to spam away. The fix wasn't to update the HTTP protocol or firefox, it was to patch the ircd so it actually checks what protocol the client is speaking (And also PING/PONG checks etc)

So, your premise that the original spec is somehow insecure to use within a browser->webserver context, is completely incorrect.

</comment></comment></comment></comment></comment><comment><USER9> This is the beauty of the web, change the server code, then serve the new client code and done.

Automagically updated. The client will never know what hit them.

<comment><USER10> Actually no, it says you need a new version of chromium, so the client will know in that case.</comment></comment>


Typos may earn Google $500m a year - <AUTHOR> http://www.newscientist.com/article/dn18542-typos-may-earn-google-500m-a-year.html

<comment><USER2> scientific paper about domainname squating.</comment>


The Internet vs. Hollywood - <AUTHOR> http://www.theinternetvshollywood.com/ <comment><USER2> Calling the megaupload seizure a "backdoor SOPA/PIPA" will instantly lose you credibility.</comment>


Ask HN: How can I be less awkward on phone calls with vendors/clients? - <AUTHOR> I recently became a product manager, and my job includes talking to vendors / potential vendors, and the occasional client. I've always had a bit of phone anxiety, but I have a particularly tough time "being smooth" on phone calls with professionals I've never met.
I try to start with a brief introduction of myself (how long I've been at the company, what my focus is, etc), but sometimes I speak too quickly or not clearly enough. And because I don't have any visual feedback, I sometimes don't know whose turn it is to speak.
I'd really appreciate any advice on how I can be better on phone calls. I think I'm getting a bit better with practice, but I'm still stumbling over my words and finding that I'm much less clear over the phone than in person with coworkers. <comment><USER2> Three suggestions:

1\. Create an outline of all of the key points you want to bring up to the person you'll be speaking with on the phone. The outline can be as detailed or as sparse as you feel you need, but having something to use as a checklist of sorts, along with any additional details that are pertinent to the conversation, will help give you a boost when it comes to stumbling over your words. And really go over your outline, because familiarity with what you're speaking about will help you instill confidence within yourself, which will help you sound "smooth."

2\. Work on leading the conversation without dominating it. There's a fine line there, but with time and practice you'll get get the hang of it. Your main goal here is to keep the conversation focused by sticking to your outline. This will help remove any awkward pauses.

3\. Smile when you're speaking. Most people sound friendlier when they smile when they talk, even if you're not sitting in front of the other person.

Hope this helps!

</comment><comment><USER3> Bring someone into the room with you (maybe a coworker at first, later a rubber duck), and speak as if you're having a conversation with them, rather than with someone you can't see.

</comment><comment><USER4> One suggestion:

Role play / practice.

Can be done with friends, partner, or in front of the mirror / with your laptop camera / facetime camera.</comment>


No JSON/MAPS interoperability in 17.0? - <AUTHOR> http://erlang.org/pipermail/erlang-questions/2014-March/078228.html <comment><USER2> Erlangers are particularly grumpy about JSON because unlike many other languages, Erlang lacks a decent default serialization and deserialization of JSON. This is primarily due to the fact that a string is a list of integers, thus making it hard to distinguish between the two, and somewhat less importantly, but still problematic, the klunkiness of the dictionaries. (This message appears to be in the context of the soon-to-come native addition of dictionaries, but as I imply, unfortunately that is not the biggest problem with JSON deserialization, the nature of strings in Erlang is. Binaries are not a precise conceptual match to a JSON string either, unfortunately; in my environment I actually use binaries that way because I can guarantee the differences won't affect me since I control both ends of the protocol, but that is not safe in general.)

This is not to say that the arguments are wrong, but I think you may not understand why Erlangers feel the way they do until you realize that Erlangers also don't generally get to experience the _advantages_ of JSON, either; when you get none of the advantages and only the disadvantages, anything looks bad, no matter how good it may be in the abstract.

This is a particularly rich irony in light of the fact that Erlang's native data model is _conceptually_ the closest language I know to natively using JSON as the only data type. Erlang has no user-defined types, and everything is an Erlang term... imagine if JS worked by only allowing JSON, so, no objects, no prototypes, etc. The entire language basically works by sending "ErlON" around as the messages, including between nodes. It's just that there's no good mapping whatsoever between Erlang's "ErlON" and JSON.

<comment><USER3> Erlang has amazing default serialization and deserialization. term_to_binary(T) and binary_to_term(B)

<comment><USER2> (I edited the last paragraph in before seeing your post here.)

<comment><USER3> The last paragraph is absolutely right. It's incredibly ironic...

</comment></comment></comment></comment><comment><USER4> The first requirement that I look for in a data interchange format is that it should be readable, because I don't want to look at binary data responses. The second thing I look at is support for encoding and decoding it.

The only three formats I've found so far that are readable and well supported are XML, JSON, and YAML. XML is too hefty and wasteful. YAML has had a bad history of insecure encoders and decoders but overall is my favorite data format. However, it still has the downside of needing a special decoder since browsers don't support it, and it requires specific indentation for its hierarchical data format which is wasteful in its own way.

That just leaves JSON in my opinion. It's easily understood and read, and native browser and Node.js encoding and decoding is more than fast enough.

<comment><USER5> I always use "python -m json.tool" to pretty-print JSON data before looking at it. I could just as easily do the same with a MessagePack or BERT pretty- printer.

</comment></comment><comment><USER6> This essentially amounts to "JSON is slower and more CPU intensive than it absolutely needs to be."

I can live with that. Any solution that people come up with, there will be folks who can point out some sort of flaw in it. Sometimes the flaws are worth paying some attention to, when fixing them might lead to some tangible benefits. It's difficult to imagine a slightly less CPU intensive replacement for JSON bringing any tangible benefits with it, though.

<comment><USER7> The lack of hypertext is a valid complaint, in my opinion, for a language designed in the web age. Sure, you can build a format on top of JSON that treats certain values as URIs, but that kind of thing should be built-in.

<comment><USER8> I don't quite follow the whole hypertext problem. I mean URIs can be encoded as strings, there's no problem there.

HTML doesn't handle URIs any differently. They're just string attributes on elements(generally).

Is the problem that there aren't clients that can generally consume the JSON and find the hyperlinks? Is the idea that the JSON should be able to be rendered as a site kind of like the whole xml/xslt idea?

I guess I just don't get what the problem is here? What would built-in uri's look like?

<comment><USER7> _HTML doesn 't handle URIs any differently. They're just string attributes on elements(generally)._

Sure it does, when it defines the semantics of the elements. HTML says "the 'href' attribute of the 'a' element is the URI of a linked resource". There's no special syntax, because it doesn't need to have; they're identified by their elements.

But on a more general format that doesn't define particular semantics to nodes, you have syntax that identifies URLs. For example, in Turtle - which is a format that I quite like - you encode strings using double quotes around the value, but URIs are encoded using angle brackets.

Example:

      dc:title "RDF/XML Syntax Specification (Revised)" ;
      ex:editor [
        ex:fullname "Dave Beckett";
        ex:homePage <http://purl.org/net/dajobe/>
      ] .

The advantage is that smart clients can parse that information and crawl the documents, generating useful data even if they don't necessarily understand this particular format. Think search engines, for example - they might not understand that <span id="author"> identifies the author's name, but they can still derive useful information for the web of pages that they crawl.

</comment></comment></comment></comment><comment><USER9> Using something other than JSON is a great idea if you don't want anyone to ever bother using your API.

<comment><USER10> Content negotiation is a great way to expose multiple serialization formats. No reason it has to be just one of the well known formats. The main tricky part is equivalence of more complex structures in JSON, for example msgpack supports more than just string keys in maps.

<comment><USER11> So now I get to support more than one format, with corresponding increases in complexity...

..But only the JSON format will have any users, and I still have to deal with anything I find objectionable about JSON.

<comment><USER10> In most systems I've deployed multi-format support it was a matter of a few extra lines of code rather than a doubling of effort. Pretty much all JSON values have obvious (aka. automatic) equivalents in other formats. JSON is truly the lowest common denominator, which is its strength.

</comment></comment></comment></comment><comment><USER11> Only an Erlang mailing list would prompt someone to complain that a document format requires valid UTF-8.

This is a glimpse of the last place on earth where relying on US ASCII is considered a positive good.

<comment><USER12> I was thinking to myself while reading the link "Why on earth would someone think UTF8 is a problem?" and then I saw it was a erlang thread. To complain about it being slow to validate while talking in an erlang thread... christ. It must be frustrating trying to deal with json, which is full of strings, in a language like erlang.

<comment><USER13> JSON decoders decode string to binaries.

[https://github.com/talentdeficit/jsx](https://github.com/talentdeficit/jsx)

Erlang has been receiving and sending data. It just like to deal well defined binary messages and it likes to encode/decode them into its own representations (records, terms) at the boundary where they come in and leave the system.

</comment></comment></comment><comment><USER14> Prefixed length formats that don't make assumptions on encoding are a very good pick. The most important thing is that once you read the length, you can just bulk-read the payload without actually parsing it, that's up to the higher layer (if parsing is needed at all).

A general purpose serialization format that requires per-char processing is a terrible pick.

<comment><USER13> Agreed. I had to implement base64 encoding to pass data through JSON, yeah it works but seems terribly wasteful.

</comment></comment><comment><USER15> > Its numbers representation is double-precision floating-point, meaning it's > incredibly imprecise and limited.

Except that JSON actually just specifies the number type as an arbitrary precision decimal number.

Many implementations use floating point numbers when decoding JSON, but that is not inherent in JSON.

My biggest complaint about numbers in json is that often times floating point numbers get turned into integers when encoding/decoding using some implementations. (e.g. (float)2 gets encoded as just 2 and when decoding, it is an integer rather than a floating point.

<comment><USER16> Well, regardless of the specification, most JSON deserializers approximate numeric values as floats, at least in the default configuration. Enough so, that the Bitcoin exchange JSON-APIs I know of all put numbers in strings. So `{"balance": "12.65334221", "currency": "BTC"}` instead of `{"balance": 12.65334221, "currency": "BTC"}`. It would easily be pretty catastrophic if there are any rounding errors in your currency calculations, and if the bug arises already in your JSON deserializer it might be hard to detect even if your program internally employs BigNums (arbitrary precision) or such.

</comment></comment><comment><USER17> JSON and Erlang just don't get along in the way you'd like them to, unfortunately. Some of that has to do with how Erlang handles (or doesn't handle) strings. Some of that was that there was not a data structure that closely mirrored JSON's structure in Erlang up until Maps were introduced.

The problem isn't really JSON - JSON is an exceptional format for what it is supposed to do - the problem is that Erlang was created for a specific purpose and that purpose wasn't to vend out strings/JSON over HTTP.

<comment><USER13> > Erlang handles (or doesn't handle) strings.

JSON string are translated to binaries. There is no reason to keep repeating oh inters=strings. Maps will help.

> The problem isn't really JSON

I think the author disagrees. He talks about the problems of "JSON". There are a few he notes:

* No binaries.

* No way to have hyperlinks

* Limited floating point number implementations

<comment><USER17> You have to translate your strings to binaries before you try to encode to JSON. A JSON encoder has no way of determining whether it should be encoding an array or a string without this. Instead of one string type, you have "strings" and <<"strings">>, and due to the lack of typing, it is actually pretty tough to keep track of which one you have. It also is an exercise in finger acrobatics to <<>> all your strings.

JSON doesn't solve every problem. It does solve the problem, quite elegantly, of creating a 'endianless' interchange format that is easily consumed, constructed, and debugged.

</comment></comment></comment><comment><USER18> Since the author seems to have a problem with text-based formats in general, here's a counterpoint by Mike Pall on the LuaJIT mailing list [1]:

"On a tangent: IMHO most binary serialization formats like BSON, MessagePack or Protocol Buffers are misdesigns. They add lots of complications to save a couple of bytes. But that does not translate into a substantial improvement of the parsing speed compared to a heavily tuned parser for a much simpler text- based format."

[1] [http://www.freelists.org/post/luajit/Adding-assembler- code-t...](http://www.freelists.org/post/luajit/Adding-assembler-code-to-Lua- programs,12)

</comment><comment><USER19> So don't use JSON when you need super high performance and be careful about parsing JSON numbers?

It may not be perfect, but compared to the complexity of the XML world and the opaqueness of binary formats JSON is a very pleasant compromise.

Shame about it not having comments though.... :-)

</comment><comment><USER20> The author suggests using MessagePack, which I hadn't seen before but looks really cool.

[http://msgpack.org/](http://msgpack.org/)

<comment><USER18> But that also uses double precision floating point number representation and UTF-8 for strings, so the only benefit (according to the arguments given in the OP) seems to be text vs. binary-based.

<comment><USER21> > But that also uses double precision floating point number representation

I don't think JSON requires the number representation to be double-precision, that can be up to the parser to decide how to represent a number. I think most people misrepresent this because the number implementation in _JavaScript_ is double-precision, but that's not necessarily true for JSON. Am I wrong about that? Does JSON require the number format to be double-precision?

<comment><USER18> I had to check but yeah, that's true, the ECMA spec even says explicitly in its intro: "JSON is agnostic about numbers", they are "only a sequence of digits".

(Unrelated observation from looking at the spec again: there's no standard/recommended decoding behaviour if an object has several members with the same key.)

</comment></comment></comment></comment><comment><USER22> >I do not have a magical format to propose to replace it

So why did you even comment in the first place?

<comment><USER23> I don't agree with you. I think that someone can point out problem without providing the solution at the same time.

<comment><USER24> He didn't just point out a problem, he actively tells people to "stop using JSON" without providing an alternative.

</comment></comment></comment><comment><USER25>
        > *  It has to be valid UTF-8, meaning it's incredibly
        > slow to validate.

If make basic mistakes about what the format allows, the rest of your comment is liable to be junk.

</comment><comment><USER26> > It's text-based, meaning it's incredibly slow to parse.

This is precisely the reason it is used so heavily. Easily readable format to reason about. And _incredibly slow_ is a pretty relative term, when you're waiting on database calls or doing other complex logic that is orders of magnitude slower, who cares how "slow" json parsing is.

> It has to be valid UTF-8, meaning it's incredibly slow to validate.

I think being able to embed all sorts of different characters and languages is, again a plus. See argument above about performance.

> Its numbers representation is double-precision floating-point, meaning it's > incredibly imprecise and limited.

This argument I don't get. I'm pretty sure I might be missing something, but in my experience you can just put a plain old integer and any parser in any language will extract as an exact integer. Nobody is converting a "1" in json into a double/float. Maybe somebody can elaborate and what the author might have actually meant?

So, really, the argument all boils down to, it's slow and wasteful. Well, while that's true I think it's pretty much been established time and time again that Moore's law has made it possible to value programmer time over CPU overhead, to a reasonable extent (i.e. if the overhead you're adding overtakes Moore's law and makes infrastructure particularly expensive). If you have a format that is human readable, easy to understand, and simple, that helps tremendously in software development and it would take order of magnitude performance hits to really make it bad tradeoff (and even the, if you weren't getting a lot of traffic, who would care?), not just 2x or 3x.

We live in a web based world, and that world is fundamentally based on a text based protocol (http) and text based messaging formats. There are plenty of valid and good reasons why it happened the way it did.

*Final Note: I would like to see some empirical evidence to compare the wasted CPU cycles and energy that JSON uses compared to if all messages were sent with msgpack or something like it instead. While my own inclination is that number would be dwarfed by the overall energy used in computation I would prefer to see evidence rather then conjecture if you're going to make a point like that.

<comment><USER21> >> Its numbers representation is double-precision floating-point, meaning it's incredibly imprecise and limited.

> Maybe somebody can elaborate and what the author might have actually meant?

I think JSON numbers are not necessarily double-precision, at least I don't think I've ever seen them specifically described this way. In JavaScript, however, numbers are double-precision, there are no real integers in JavaScript. So maybe the author misrepresented JSON numbers because JavaScript numbers are double-precision. But that isn't necessarily the case AFAIK.

</comment></comment><comment><USER27> Ok, I understand your argument, now tell me a better format to create an API, Thanks ...

<comment><USER7> Turtle!

</comment></comment><comment><USER28> If msgpack is able to match JSON for serialization/deserialization, couldn't you make an API in JSON and offer msgpack as an alternative format?

<comment><USER29> In a project I'm working on, we do that with Protocol Buffers. Our main client uses protobuf but we still provide JSON for other clients. We also use the JSON API for debugging.

</comment></comment><comment><USER30> Here the reasons why i use JSON:

* It's text-based, meaning it's readable and easy to parse.

* It has to be valid UTF-8, no hassle with other formats.

* Its numbers representation is double-precision floating-point, i can choose what i want.

Who cares? Use what you want and what solves your problem at the best way.

</comment><comment><USER31> Servers aren't CPU bound anymore, there is no need to worry about that...

<comment><USER32> It depends a lot on the service that you provide. I provide compute services. Most of my servers are CPU-bound most of the time.

</comment></comment><comment><USER33> Yes, because XML is so much more compact.

Oh, wait....

<comment><USER26> I don't see xml mentioned once, I'm sure he would say it's worse. He'd clearly probably advocated some sort of binary format, since he mentioned msgpack. Did you even read the comment?

</comment></comment><comment><USER34> Oh, now that you mentioned it, I'll use XML, It's very cool and compatible with new technologies, like a new thing of Microsoft called C#.</comment>


Effects of Bullying Last Into Adulthood - <AUTHOR> http://well.blogs.nytimes.com/2013/02/20/effects-of-bullying-last-into-adulthood-study-finds/

<comment><USER2> _Bullies who were also victims were particularly troubled: they were 14.5 times more likely to develop panic disorder as adults, compared to those who did not experience bullying, and 4.8 times more likely to experience depression._

Where do they find people who weren't bullied or bullies during childhood? It's like finding people who haven't lived around EM radiation or males who haven't ever viewed pornography.

<comment><USER3> Not everyone experiences bullying, or at least not beyond one time. Once the bully realizes you fight back, he'll look for easier prey. It's quite conceivable that people won't even remember the episode if they fought the bully off.</comment></comment>


OpenSnitch – A Linux clone of the Little Snitch application firewall - <AUTHOR> https://github.com/evilsocket/opensnitch <comment><USER2> I really hope this tool takes off!

The problem with existing tools (iptables & co.) is that they are pretty much useless for "ordinary power users". I don't want to spend my precious time checking logs and trying to figure out if yeat another tool / extension / ... decided it needed to phone home (or worse). Ideal UI? Block everything, inform me about it (via unobtrusive non-modal message notification) and let me decide on a case-by-case basis what to do with such traffic in future. Bonus points if you keep the log of events so I can traverse and approve / forbid them at time of my choice. Kind of like NoScript, but better.

I don't know how close to that LittleSnitch / OpenSnitch are, but I would love to see that as a standard part of OS.

<comment><USER3> Glasswire (paid version) is nearly there - Only annoyance is when using across multiple users on the same machine. An app is blocked by one user cannot be unblocked easily by a non-admin (e.g. one of my kids) - have to switch user, unblock and switch back. Annoying if I do actually want to allow some traffic through.

edit - yes Glasswire blocks by executable rather than port.

<comment><USER2> Unfortunately it is not available for Linux.

</comment></comment></comment><comment><USER4> Apparently, the whole things needs to be run as root, since it's all one huge blob.

Hopefully, this'll eventually get separated into a daemon which does all the superuser bits and exposes a single API for a client GUI to consume.

<comment><USER5> OpenSnitch author here ... that's exactly the direction the project is going, C++ daemon running as root and low privileged UI in Python or whatever. The current implementation is more of a PoC/test to see the whole logic working before starting the real thing :)

<comment><USER6> Why C++? The backend only has to read ftrace events, and Python should be fast enough for that.... And why root? Can't you just create a dbus connection, open your fd to the ftrace pipe, and then drop privs to a nonroot user?

<comment><USER5> OpenSnitch is not only about ftrace, check the NFQUEUE handling, moving to native will improve performances and stability. Also, it requires root because that's the only way it can install the iptable rules it needs in order to function properly.

<comment><USER6> The iptables rules are static though, aren't they? And they have bypass enabled, so you should be able to load them once at system boot time and leave them there to default to allow.

As far as nfqueue, I googled around but I wasn't able to find out what perms you need in order to communicate with netlink. I assumed you could open an fd and drop perms but it looks like it might not allow that. I agree that eventually you'd need a pretty robust multithreaded app to handle large packet flows without adding too much latency... it seems like quite a big burden just to authorize specific applications to make specific network connections.

<comment><USER5> as long as i know, you definitely need root to communicate with netlink .... i don't think there're gonna be large packet flows, only first connection packets tnx to conntrack, it's doable :)

</comment></comment></comment></comment></comment></comment><comment><USER7> I just made an AUR package for this: [https://aur.archlinux.org/packages/opensnitch- git/](https://aur.archlinux.org/packages/opensnitch-git/)

This is cool stuff! Wanted to have this kind of thing for a long while. Thanks for merging my changes so quickly too. Packaging would not have been possible without it.

<comment><USER8> Thank you so much for your work!! Will install it on my arch as soon I get home. :)

</comment></comment><comment><USER9> It's hard to believe there wasn't a credible little snitch like application for Linux yet. Even more why Objective Development themselves did not try to port their very successful product to other platforms. I hope opensnitch gets some community love.

<comment><USER10> I suspect most Linux users just use iptables and/or /etc/hosts. That's what I've done since making the switch from Mac.

<comment><USER2> Curious: how do you detect that some plugin is phoning home with iptables? Especially if it is cleverly written to only do it when there is lots of other traffic?

<comment><USER11> You can use the owner extension: [https://www.frozentux.net/iptables- tutorial/iptables-tutoria...](https://www.frozentux.net/iptables- tutorial/iptables-tutorial.html#OWNERMATCH) , which can filter based on the PID of the process which created the packets.

But what we generally do is, you know, not run plugins that phone home :).

Edit: I just looked on a Linux machine - things have changed a little. That used to be my go-to document for iptables, which is why I referred you to it. You probably want to consult something more up-to-date.

In any case: iptables can do filtering based on who created the packets.

Even later edit: it probably goes without saying, but just in case -- this solves only half the problem, because it can only identify the process based on its PID. This makes it pretty trivial to overcome PID-based rules. The usual solution, of course, was to filter based on UID and run the program under a separate account.

I don't know if this got solved in the meantime, I haven't used iptables in a while now.

</comment></comment></comment></comment><comment><USER12> I wonder how it compares to Douane[1] which is touted as the alternative to Little Snitch.

I wasn't very happy with Douane since it was a kernel module and a memory bug (Think it missed a free) caused kernel panics on every single boot after an update. But other than that I would say it was pretty good.

[1]:[http://douaneapp.com/](http://douaneapp.com/)

<comment><USER13> I remember looking into Douane a while ago and was not impressed. Rather than implementing all of the rules and policy in userspace (as OpenSnitch does) it implements the rules in kernelspace. It also has a bunch of questionable technical decisions in how policies are handled, especially when it comes to "edge cases" like processes with long paths[1] or connections where the socket file descriptor is greater than 8 or something like that[2].

My main complaint about implementing all of these things in kernel space is that it's simply not necessary -- with netfilter_queue and connmark you can relay all decision making to userspace without losing any generality. The only thing that you might argue is a benefit of using a kernel module is that figuring out the "path" for an application _might_ be easier but I'm not sure I agree. Also Douane simply will not work properly with containers because of how it assumes that everything is in the host namespace.

As an aside, I decided to write my own application-level firewall for GNU/Linux[3] (mainly as an exercise to myself to learn Rust as well as learn more about low-level network programming in Linux). My plan is to make it far more modular than OpenSnitch with an client API so the GUI can be completely separate (and also perhaps allowing different clients to have different policies).

[1]: [https://github.com/Douane/douane- dkms/blob/master/douane.c#L...](https://github.com/Douane/douane- dkms/blob/master/douane.c#L217) [2]: [https://github.com/Douane/douane- dkms/blob/master/douane.c#L...](https://github.com/Douane/douane- dkms/blob/master/douane.c#L669) [3]: [https://github.com/cyphar/whistled](https://github.com/cyphar/whistled)

<comment><USER14> Looks very interesting! Would you like to add LDAP support, maybe in a modularized way to store rules "somewhere" and provide a mechanism for mandatory application of these rules on clients ("enforce rules from trusted storage x")?

Others could build GUIs around the storage (LDAP, SQLite, whatever) and we could share rules via a website. That would be a great help for many users! Thanks!

<comment><USER13> > Would you like to add LDAP support, maybe in a modularized way to store > rules

My thinking is to make it so that you just have a "dumb" daemon which has the concept of a process requesting the ability to connect to an IP/unix socket and sends requests over gRPC to clients that make access decisions. So there's no long-term storage of rules in the daemon (except possibly in some edge cases).

In any case I'm still writing a PoC so it's a bit early for features like that.

</comment></comment></comment></comment><comment><USER15> I love using DTrace for network monitoring. I wonder what's the simplest way to integrate it with pf to achieve a similar solution to Little Snitch, except with an htop-style interface :)

[http://www.brendangregg.com/DTrace/connections](http://www.brendangregg.com/DTrace/connections)

[http://www.brendangregg.com/DTrace/tcpsnoop](http://www.brendangregg.com/DTrace/tcpsnoop)

</comment><comment><USER16> I was surprised to see that it's written in Python... I was expecting something lower-level for this type of application.

The other thing worthy of note is that it appears every single packet will need to be processed through this application; necessary for it to do its job, but will likely have a significant effect on performance.

<comment><USER17> If performance becomes an issue, the packet processing stuff could be split out into a faster daemon.

I'm surprised, I expected this to be an iptables frontend.

<comment><USER18> What would a "pure iptables front end" be and how would it learn about connection attempts? (Serious question, it's quite possible I'm forgetting an API)

The used technique, redirecting initial packets to a netfilter queue and then marking the connection to offload further processing to the kernel seems like a reasonable way to do this from userspace.

<comment><USER17> I don't know enough about Linux networking - I didn't realise the distinction between iptables and netfilter. Off to do some reading - thanks.

<comment><USER18> (I interpreted "iptables frontend" as probably meaning something that just generates iptables rules, that's why I was asking)

netfilter is the underlying kernel infrastructure, that's used e.g. by iptables to set rules for packets. From this [https://github.com/evilsocket/opensnitch/blob/master/opensni...](https://github.com/evilsocket/opensnitch/blob/master/opensnitch/snitch.py#L33), it looks like OpenSnitch uses iptables to set rules so that the kernel delivers outgoing packets that don't belong to an existing connection to a queue. It then can use said queue to only intercept those packets – if it lets them pass, a connection will be created and further packets will not be passed to/handled by OpenSnitch. It touches the first packet of each outgoing connection, but not all traffic.

</comment></comment></comment></comment></comment><comment><USER19> I created a similar app for macOS called Security Growler. I have some bugfixes to work on for Sierra, and Linux support is waiting to be merged, but basically it's a monitoring tool (not a full firewall) that also supports watching logfiles for events.

[https://github.com/pirate/security- growler](https://github.com/pirate/security-growler)

</comment><comment><USER20> The timing is impeccable! I just switched from a MacMini running OS X 10.10 to a custom-built PC running GNU/Linux, and one of the few things I miss is Little Snitch.

</comment><comment><USER21> Great job! That was for sure a missing package for Linux. Side comment: the author seems to work 24/7 for his open projects(!).. im very impressed.

<comment><USER5> Ahah not really 24/7, but you're almost there :) it's my way to repay the OSS community for everything I learned from OSS during my life.

</comment></comment><comment><USER22> So, Little Snitch has lots to block because MacOS is proprietary and filled with proprietary software which would be inclined to track users for the goals of the developers (which are only sometimes aligned with the interests of users)…

On GNU/Linux, is this much of an issue? Most programs seem to offer opt-in on metrics related stuff. If you assume OpenSnitch is set to match the opt-in settings whenever they are present, what sort of stuff is remaining to block at all? I.e. if people use this, what stuff are they seeing blocked?

<comment><USER23> Out of the box, Ubuntu doesn't behave well. [1]

Let's not forget applications such as browser plugins.

[https://fixubuntu.com/](https://fixubuntu.com/) [1]

<comment><USER22> I think that's all gone now, as of a year ago. [http://www.omgubuntu.co.uk/2016/01/ubuntu-online-search- feat...](http://www.omgubuntu.co.uk/2016/01/ubuntu-online-search-feature- disabled-16-04)

But even so, that can be disabled via the stuff on that site.

<comment><USER2> That's not the point. Sure, everything can be disabled - if you know there is something that should be disabled. Do you? I am 100% sure I don't. LittleSnitch notifies you about such activity and conveniently offers to block it. But it's the notifying part that makes the difference (which iptables can't do because of all the noise on common computer setup).

<comment><USER22> Yeah, but what I'm getting at is basically: running LittleSnitch on MacOS makes it clear how much activity is happening. Surely OpenSnitch on GNU/Linux would do the same. But I would assume that some knowledgeable people would know about the extent of the difference generally. I suspect that MacOS programs are _far_ more rampant in calling home, and the GNU/Linux stuff would mostly just be proprietary programs doing it. So, I was asking if people know about this stuff generally…

</comment></comment></comment></comment></comment><comment><USER24> This is absolutely great news! Just the other week I was again researching every option, from Subgraph OS's fw-daemon to the Douane firewall.

</comment><comment><USER25> Can such thing really improve security? I remember the times when Desktop Firewalls like ZoneAlarm got popular, there were dozens of tech talks that showed how baby simple it was to bypass them. I think it was common sense these times that this tools are nothing than SnakeOil. They are useless against real Trojans and only cause a lot of work for the user with all that false positives. In worst case it's blocking applications from self updating which can lead to a less secure system.

Has this changed nowadays? Especially when we are talking about little snitch which has a really good reputation like I noticed the last years.

<comment><USER26> Since this is a Linux clone:

> They are useless against real Trojans

Highly doubt anyone will consider it as a way of protecting against trojans.

> In worst case it's blocking applications from self updating which can lead > to a less secure system.

Since this is mostly done on the package management level, it makes sense to use a tool similar to Little Snitch. You're detecting how apps phone home and nothing more. I would take it a step further and disallow some apps to connect to the Internet at all, and allow some apps to contact only certain web pages. Seems like a good way without spending a lot of time playing with firewalls.

<comment><USER25> >You're detecting how apps phone home and nothing more.

But only the harmless or respectively naive ones?

</comment></comment></comment><comment><USER27> Interesting.

I began working on a application firewall like this a little over 6 weeks ago for my thesis, as I was mildly disappointed there wasn't a GNU/Linux version of this (yet) and I considered it an interesting topic to dive into.

<comment><USER28> The point of a thesis isn't to build something useful and practical, it's to show you understand the concepts of computer science.

<comment><USER29> I expect student to be able to demonstrate at least a little bit of practical thinking too. Just demonstrating understanding of concepts won't get your very far...

</comment></comment></comment><comment><USER30> It is tools like this that make Linux a viable replacement for Windows for desktop use for me. I love running all apps through ZoneAlarm on Windows and this looks like it would be a fine substitute.

<comment><USER31> Last I heard, ZoneAlarm itself was phoning home. Granted, this was in 2006. Didn't trust it since though.

<comment><USER32> As I recall (and just for completeness), Little Snitch phones home too - unless you use it to block itself.

I definitely appreciated it when I was using OS X though.

</comment></comment></comment><comment><USER33> Is there a similar application for Windows? I was able to google NetLimiter, has anyone used it and can share how it compares?

<comment><USER34> Glasswire seems quite good, though you have to buy it in order to get the basic "ask to connect" feature. I've been planning to try it since forever. Zonelarm is nice too (or at least it was when I used it years ago).

<comment><USER35> The problem I have with Glasswire and similar products is that you can make calls through other Windows APIs (I don't know if that's the correct term for this but you get the idea). Especially if you run it as administrator. That means that if they want they can hide themselves from the firewall tab (the standalone .exe I mean) and make calls that will only show in other places like System or Internet Explorer. Hard to monitor or manage that.

I hope they do something about this in the new version of Glasswire that is about to be released.

<comment><USER17> Post in their forum with a list of the APIs they're not catching. Perhaps this is a limitation of the LSA (?) they're using to monitor and control traffic?

</comment></comment></comment></comment><comment><USER36> I've been looking for something like this for ages.

It's possible to block ports, PIDs and Users from accessing the network using iptables but it's not possible (easily) to restrict access by process name.

The only issue I have is that is runs on a single core using 100%, CPU temp ramps up to 82'c.

</comment><comment><USER37> Awesome. I used to love Little Snitch!

</comment><comment><USER38> Since when is a clone a port?

<comment><USER39> What makes this a clone?

<comment><USER38> OpenSnitch is an unsanctioned recreation by an unrelated party of Little Snitch's functionality, appearance, and name.

How is it not a clone?

<comment><USER23> It's not a clone. LittleSnitch is more functionally rich. The name is misleading. You can take pcap traces on applications, plot bandwidth usage and more.

Little snitch is closer to GlassWire for Windows [1] then OpenSnitch.

[1] [https://www.glasswire.com/](https://www.glasswire.com/)

Let's not start calling every application firewall a clone.

<comment><USER38> _> The name is misleading._

I think the name is very clear for the purpose of discerning the creator's intentions.

 _> Let's not start calling every application firewall a clone._

We're not. We're calling this specific project, which explicitly describes itself in its header as _" a GNU/Linux port [sic] of the Little Snitch application firewall"_ a clone, because that is its stated aspiration. That it hasn't yet copied all of Little Snitch's features after 17 days of existence doesn't countervail that.

<comment><USER23> > a clone, because that is its stated aspiration.

Thanks for the clarification. In that context then calling it a clone makes perfect sense. All the best to the project. LittleSnitch is great and to have a full clone on Linux would be fantastic!

</comment></comment></comment></comment></comment></comment><comment><USER40> What is the purpose of an "application firewall" in an open source world?

If I have the source code and I am curious I just read it. I have yet to see any source code that attempted to obfuscate opening sockets.

Sometimes I run programs with ktrace (strace for Linux folks I guess) and look at the calls.

But truthfully in most cases controlling DNS catches most if not all of today's applications' attempts contact the mothership.

I do not use a third party cache, I maintain a custom root and can use it to block wildcarded domains, something that cannot be done with /etc/hosts. I do make extensive use of the HOSTS file but not for blocking.

I can also redirect traffic to localhost servers where I can log requests and analyze the captured packets. For instance if I want to reverse engineer the protocols used.

In my opinion an "application firewall" is a misnomer. IMHO a "firewall" operates on incoming packets from _other_ computers, not packets originating from the computer running the firewall.

If a Windows user wants to run a "firewall" then IMO they need an additional computer, e.g., a gateway they control. This is the way to stop the telemetry, IMHO.

I think Microsoft puts some application they call a "firewall" on Windows. IMHO that is misleading, but not surprising considering the source.

In an open source world, in the event a particular user does not "have the time" to read source code or even grep it for clues, chances are that some other user does have the time and compiles all his programs from source. It is always possible that an application's "phoning home" behaviour could be documented by such users in public forums, etc.

What if an application hard codes an IP address? Answer: I see it in the source code. NB: I very rarely see this in practice. Apparently few people can maintain a stable IP.

<comment><USER13> > What is the purpose of an "application firewall" in an open source world?

Aside from the problems with trying to read the source code for every application on your machine (which I guarantee you have not done), security is all about depth.

If an application is compromised or contains network functionality that doesn't do what you would like (and assuming you don't want to have to patch it and rebuild it) then something like this is incredibly useful. Not to mention that (unfortunately) we don't live in a completely free software world, so something like this is very useful if you're forced to run a proprietary program.

> But truthfully in most cases controlling DNS catches most if not all of > today's applications' attempts contact the mothership.

Okay, but what if the application hard-codes the IP address? For an example of a normal project that does this, look at Tor.

And even if it doesn't hard-code the IP address how do you dynamically add entries to /etc/hosts? Are you tracing every process on your system and adding entries to /etc/host as soon as the process tries to gethostbyname(2) -- how do you deal with the fact that this will slow down your programs significantly? And what if you want to handle different applications differently?

There definitely is utility in a tool that can do all of this dynamically, per-process and also has full support in the Linux kernel already built in without the need to generate /etc/hosts in a horrifically racy way.

> IMHO a "firewall" operates on incoming packets from other computers,

Yes, and an "application-level firewall" operates on packets from applications. The term firewall is used to describe the "operates on packets" part, not on the "from applications" part of the definition.</comment></comment>


iPhone 6, Apple Watch features: Android's been there, done thataz - <AUTHOR> http://www.networkworld.com/article/2604374/opensource-subnet/iphone-6-apple-watch-features-androids-been-there-done-that.html#twitter

<comment><AUTHOR> For those who live in an Apple bubble, there may have been something new and interesting in Apple's keynote today. But from outside the bubble, it was a big yawn.</comment>


Determining A/B test sample size - <AUTHOR> http://37signals.com/svn/posts/3004-ab-testing-tech-note-determining-sample-size

<comment><USER2> Somebody really needs to write a Bayesian takedown of all these A/B testing articles. A/B testing is a Bayesian decision problem. There's really no other way to think about it. Determining sample size and frequentist confidence intervals are only relevant insofar as they approximate Bayesian concepts.

The issue is the proper tradeoff between exploration and exploitation. What drives the decision is outstanding uncertainty conditional on the data observed (not conditional on the null hypothesis of zero effect and some non- sequential iid sampling process), the discount rate (which is totally absent in this article), and the reward structure (which is not a Type I and Type II error).

The absurdity of the frequentist approach is clear from the admonition not to look at the results of the tests too often.

<comment><USER3> I think even a Bayesian approach will have to grapple with the issue of looking at the results too often. The problem is that if you make your decision on "when do I stop testing", dependent on the test results so far, then the test results can be biased.

I'm sure you're aware of this, but I'm just trying to clarify the idea for other readers.

The idea is not well-illustrated in the article. (Although the article does provide some usable guidance until the whole Bayesian framework gets built and populated with correct parameters, like the reward structure.)

So, to be concrete -- Suppose you're flipping coins and you figure (by some procedure) you need 100 flips to reach significance. By the 70th flip, you observe that p(head) ~= 40/70 ~= 57%, so you decide to stop the test because clearly you're not dealing with a 50/50 coin. That's not OK, because you'll always see favorable and unfavorable excursions in a series of coin flips -- if you choose to stop in the middle of such an excursion, you'll bias the result. You've made the stopping time dependent on the observed values.

In some situations you can do this (it's related to <http://en.wikipedia.org/wiki/Optional_stopping_theorem>), but the way that I described above is not one of them.

<comment><USER2> No this is actually a common misunderstanding and gets to the heart of the difference between conditioning on the data vs considering the sampling process. At the 70th flip your best guess is that it is 57%, given a uniform prior. It's perfectly fine to stop based on the results you have, that doesn't change the likelihood of seeing what you saw. Imagine looking each time, clearly your best guess is the sample mean unless you have prior knowledge.

What's confusing is thinking about the sampling distribution. But what might have happened in some other world is of no consequence if you condition on the data rather than the parameter.

This is the likelihood principle. <http://en.wikipedia.org/wiki/Likelihood_principle>. See the example there and how it relates to sequential trials. It's actually rather deep. Other good links are:

[http://books.google.com/books?id=_ravDT9e8nMC&lpg=PA17&#...](http://books.google.com/books?id=_ravDT9e8nMC&lpg=PA17&dq=stopping%20rule%20robert&pg=PA15#v=onepage&q=stopping%20rule%20robert&f=false)

[http://books.google.com/books?id=oY_x7dE15_AC&lpg=PA27&#...](http://books.google.com/books?id=oY_x7dE15_AC&lpg=PA27&dq=likelihood%20principle%20berger&pg=PA27#v=onepage&q=likelihood%20principle%20berger&f=false)

[http://projecteuclid.org/DPubS?service=UI&version=1.0...](http://projecteuclid.org/DPubS?service=UI&version=1.0&verb=Display&page=toc&handle=euclid.lnms/1215466210)

<comment><USER3> My only point is that any kind of analysis has to be careful about the way its mathematical assumptions relate to how the real-life experiment is conducted.

I'm not even going near the question of whether the Bayesian approach is "better" than the frequentist approach.

I was trying to point out that the frequentist analysis in the OP does make assumptions about the nature of the experiment (that you will run exactly N trials) and that if you break those assumptions by stopping the test for some N' < N because the answers are looking good, then you'd better understand that your earlier analysis did not apply.

And in another reply, I wanted to add that there is a frequentist answer (the Wald test) to the practical question: Can you widen the scope of the analysis so that I _can_ stop early if I'm getting results that point strongly in one direction?

Being sure that your assumed sampling distribution matches the actual experiment is key, even in the Bayesian case.

My graduate statistics class was taught from Berger, your second link, so I'm broadly sympathetic to the "Bayesian choice" -- but more important, I wanted to give some usable insight to someone who just wants to do an A/B test.

<comment><USER2> Yes, examining the data will mess up the sampling distribution and invalidate the standard Wald test. But it's absurd in the AB testing context to advocate not acting on your data. Of course it's also absurd to look at conventional p-values if you do. So it's a bit of a Catch-22.

All this confusion goes away if you realize you are interested in p(lift | data) rather than p( data | lift=0). The sampling distribution -- the distribution of the statistic under repeated sampling, p(data | lift=0) -- does not play a role in Bayesian statistics. Obviously the "model" (likelihood/prior) does, but this doesn't include the experimental procedure provided that the experiment is only based on observed data.

AB testing, as a decision procedure, is an area where I don't think the standard frequentist - Bayesian debate applies. The Bayesian decision rule is the _only_ profit maximizing solution. That said, I"m sympathetic to being practical. But all the confusion and conflicting advice related to AB testing stems directly from trying to fit it into a frequentist frame.

</comment></comment></comment></comment></comment><comment><USER4> I rarely see many people take into account the opportunity cost of letting a really close A/B test reach 99.99% confidence when the benefit is by definition very marginal (that's why its taking so long, right?). I mean, is it really that bad to go on "close enough" results and move on to bigger and better tests?

<comment><USER5> In academia, we used p values of .95 or greater. I was taught that in business, though, the rule of thumb for making decisions is more like .8, and that's typically the standard I use as well.

</comment></comment><comment><USER6> Another way to see this, is to use this online calculator: [http://visualwebsiteoptimizer.com/ab-split-significance- calc...](http://visualwebsiteoptimizer.com/ab-split-significance-calculator/)

</comment><comment><USER7> If you are lazy, you can get the functions coded in PHP here: <http://abtester.com/calculator/></comment>


Accidentally destroyed production database on first day of a job - <AUTHOR> https://www.reddit.com/r/cscareerquestions/comments/6ez8ag/accidentally_destroyed_production_database_on/ <comment><USER2> So, taking this story at face value, I'd say the obvious: not his fault.

If your system is built in such a way that the production database can be nuked from the most junior developers command line, then that junior developer is definitely not at fault.

But this story just doesn't pass the smell test. I've worked in some sloppy, slipshod places and even in the worst of the worst dev shops there's no way this could have occurred.

Either this person found the most absolute, bush-league shop there is, or he or she or xhe is completely full of crap.

</comment><comment><AUTHOR> For me there's too many eye brow raising parts to this story so i'm sceptical of its validity. Still, it prompts those 'did you hear about the x that done y and z hit the fan' stories.</comment>


Key things to keep in mind when building a marketplace - <AUTHOR> http://parkfy.io/key-things-to-keep-in-mind-when-building-a-marketplace <comment><AUTHOR> Which other things would you add?</comment>


We know what you're doing - <AUTHOR> http://www.weknowwhatyouredoing.xyz/ <comment><USER2> Funny website! these status updates or posts are pulled direct from Twitter's API and are available to anyone with knowledge of how to use the API and a little web programming knowledge. Whether these status updates come from Facebook or Twitter is irrelevant, the lesson is still the same: "Our work to improve privacy continues today." – Mark Zuckerberg</comment>


Fifth RISC-V Workshop: Day Two - <AUTHOR> http://www.lowrisc.org/blog/2016/11/fifth-risc-v-workshop-day-two <comment><USER2> I am anxiously awaiting the videos, so this is welcome info, thanks! Any idea when the videos will be posted?

<comment><AUTHOR> Based on the timing for past ones, I'd say before 2017.

[https://riscv.org/workshops/](https://riscv.org/workshops/)</comment></comment>


Vanity Fair writer agrees to be waterboarded in a demonstration, video - <AUTHOR> http://www.vanityfair.com/politics/features/video/2008/hitchens_video200808

<comment> patrickg-zill I like Hitchens, however, the waterboarding I saw in the video does not match the description of waterboarding on Wikipedia: "which involved stretching cellophane over his mouth and nose and pouring water on his face to create the sensation of drowning".

I was under the impression that in Hitchens' case there was no cellophane over his mouth and nose. Also the inverted (head is lower than feet) placement of the person was not done either, as Hitchens seems to be on a level surface. The reason for being inverted is supposed to be both a loss of control, plus it is easier to stimulate the gag reflex.

<comment><USER2> Good points (though I suppose they didn't use cellophane during the Spanish Inquisition either). Even more than that is this:

 _flooded more with sheer panic than with mere water, I triggered the pre- arranged signal and felt the unbelievable relief of being pulled upright and having the soaking and stifling layers pulled off me_

Real torturers don't do pre-arranged signals. This is a huge difference. It means that real waterboarding and what Hitchens endured aren't even in the same category. Hitchens' experience would be better described as a kind of lower bound for what people being waterboarded go through. And he does in fact say so in the final paragraph.

Edit: interestingly, it turns out that he didn't give the pre-arranged signal. He thought he did, but what actually happened was that he lost consciousness.

<comment><USER3> He lost consciousness? I thought he said he practically threw the metal pieces to the ground, to the extent he could even though his hands were bound.

<comment><USER2> _I was completely convinced that, when the water pressure had become intolerable, I had firmly uttered the pre-determined code word that would cause it to cease. But my interrogator told me that, rather to his surprise, I had not spoken a word. I had activated the "dead man's handle" that signaled the onset of unconsciousness._

I interpreted this to mean that he lost consciousness and that the (what shall we call them...) administrators were the ones who made the decision to stop. Reading it again, though, I see that's not obvious. I confess I haven't yet found the stomach to watch the video. Perhaps it clarifies things?

Edit: perhaps his meaning was that he felt himself blacking out, thought he gave the spoken signal, but in fact gave a nonverbal (but still pre-arranged) signal. In any case, the important point is that there _were_ agreed-upon signals to stop the torture, whether he used them or not.

<comment><USER4> _I haven't yet found the stomach to watch the video_

You're in for a disappointment, the video is a lot less frightening than they make it seem. It would be laughable, if the topic wasn't so serious.

</comment></comment></comment></comment></comment><comment><USER2> Hitchens is one of the leading intellectuals of our time, as well as a great wit and a master of the English language. Referring to him as "Vanity Fair writer" is like referring to Orwell as "Former restaurant worker".

<comment><USER5> _Hitchens is one of the leading intellectuals of our time_

Sorry, I couldn't downmod that hard or fast enough. Hitchens is a warmed-over Trotskyist. The fact that he _ever_ had doubts about water torture's status as torture should give you a clue into his mental state.

<comment><USER2> Really? I'm curious why you say that, and also why you think the two ("warmed- over Trotskyist" and "leading intellectual") must automatically be incompatible. I certainly don't admire him in every respect. But he changed a lot since 1968, and even then had an individualist streak that was a little deviant for the hard left.

Edit (responding to your edit :)) - I don't know of any evidence that he doubted it before. I would guess the point of the experiment was more to be able to write about it from experience.

<comment><USER5> I guess I've just recoiled against everything he's said. For a sample, look under the heading "On the 2003 invasion of Iraq".

<http://en.wikiquote.org/wiki/Christopher_Hitchens>

It doesn't warrant much elaboration. I mean,

 _I, for one, will not have [the Vietcong] insulted by any comparison to the forces of Zarqawi, the Fedayeen Saddam, and the criminal underworld now arrayed against us. These depraved elements are the Iraqi Khmer Rouge._

Well, whatever. The vietcong [1] are still great heroes to him, I suppose. Fine. But the motivations of ordinary men don't change from place to place, and the various arab defenders and the vietnamese communists are almost surely identical morally. His defense of the Iraqi war is pure mind-fuck. I'm not completely against the war, but I understand its grand strategic purpose: To secure vast and necessary oil reserves from encroachment by Russia and China (the latter has been securing incredible resources in Africa, for example. This is no small threat.) But what's his motivation?--it's impossible to say. He just seems inspired by dead ideology.

[1] There was no shortage of atrocities or terrorist acts committed by the vietcong. I understand this as asymmetrical warfare. Hitchens understands this as good vs. evil. Specifically, good.

<comment><USER2> It seems we share a distaste for ideologues. You just think Hitchens is more of one than I do. You could be right.

Hitchens on the Iraq war is a little puzzling, I agree. I think it has perhaps more to do with his own evolution than with the matter as such. It's hard to imagine him supporting that war many years earlier.

Anyway, as I said, I like his writing. Looking over that quote page you linked to, I ran across this quintessential statement, about Michael Moore:

 _Europeans think Americans are fat, vulgar, greedy, stupid, ambitious and ignorant and so on. And they've taken as their own, as their representative American, someone who actually embodies all of those qualities._

I just think that's brilliant. And it makes me laugh. Ok, now I'm really going to get flamed... I had better stop.

<comment><USER4> _Ok, now I'm really going to get flamed... I had better stop._

He's a skillful writer, is very opinionated, and has a hobby of arguing well against fashionable opinion - Mother Teresa, for example.

One person here likes him, another doesn't? That's not much of a shocker...

<comment><USER2> No, I was expecting to get flamed because the discussion was political (enough), offensive (to somebody, surely), and not about startups or Google or Lisp. "Flamed" was hyperbolic. But I'm glad I was wrong.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> So is the 'flag' button for stuff like this, that is not hacker news in the slightest? What next, a series of taser articles?

</comment><comment><AUTHOR> He doesn't even last 30 seconds. Horrifying.

<comment><USER7> "CIA officers who have subjected themselves to the technique have lasted an average of 14 seconds before caving in."

</comment></comment><comment><USER2> If anyone's still reading this thread, I ran across a great little analysis by George Packer that is both admiring and critical of Hitchens:

[http://www.newyorker.com/online/blogs/georgepacker/2008/07/i...](http://www.newyorker.com/online/blogs/georgepacker/2008/07/i-came- back-fro.html)

</comment><comment><USER8> William Thackeray lives !!!</comment>


NASA confirms that the 'impossible' EmDrive thruster really works - <AUTHOR> http://www.digitaltrends.com/cool-tech/researchers-conduct-successful-new-tests-of-emdrive/ <comment><USER2> Remember the faster-than-light neutrinos? Where they repeated the experiment multiple times with the same result? And nobody could find a plausible explanation for an error? And then, some months later, they found it was just a bad cable.

The sane rule of thumb on these kinds of experiments that seem to contradict basic physics is to assume it's just an error in the experiment or the data calculations. Even if they did it multiple times. If this gets replicated by multiple independent teams worldwide with different experiments - then we can talk about new physics. But it's important to understand how extremely unlikely that is.

The best you can learn from these kind of stories is how hard it is to get science right and how subtle errors can be.

Don't get me wrong: I'd love to see some star-trek-like science becoming real. But it certainly doesn't help to replace critical thinking with wishful thinking.

<comment><USER3> I'll agree that experimental error is the most likely explanation by far but I think there's still a noticeable chance that the explanation is some novel effect that doesn't actually violate conservation of momentum. If I were to give a break down on my expectations they'd probably be something like

      90% Experimental error
      9%  Unexpected and novel consequence of current physics
      1%  New physics that doesn't actually violate momentum conservation
      ~0% Violation of conservation of momentum.

But this has gone the point where even if it's experimental error I expect the mechanism will be at least somewhat interesting, as with the Italian speed of light experiment.

<comment><USER4> I think violation of conservation of momentum is more likely than new physics. Basically, if this thing produces a general relativity effect, then it is possible that momentum is not conserved because the underlying metric does not have translation symmetry. (GR Energy Momentum conservation would still be in effect in that case, but classical momentum conservation would not.)

Apart from that, I am unhappy about your percentages, I think the non experimental error explanations are an order of magnitude less likely.

<comment><USER5> > Basically, if this thing produces a general relativity effect, then it is > possible that momentum is not conserved because the underlying metric does > not have translation symmetry.

Given the setup, it seems _highly_ unlikely that this thing produces something that requires a GR explanation. The energies aren't high enough; there's no high gravitational field or high acceleration.

> I think violation of conservation of momentum is more likely than new > physics.

But if GR is out, then violation of conservation of momentum _is_ new physics.

<comment><USER4> I agree, or actually I assume that the disagreement is only about words. I would not call it new physics, if, for example, we have to couple quantum fields to GR in a not straightforward way, so in the case were we already know all the parts but not the specific combination of the parts. I would only call it new physics if we have to rewrite basic textbooks.

<comment><USER5> If this showed us how to couple quantum fields to GR, that would be pretty good. Personally, I would consider that "new physics", given how unclear it is how to do so at the moment. If doing so doesn't significantly change either GR or quantum, however (and so the basic texts are still valid), I could go with your view.

</comment></comment></comment></comment></comment></comment><comment><USER6> Headline is wrong. Correct topic sentence from article :

        "In essence, by utilizing an improved experimental procedure,
         the team managed to mitigate some of the errors from
         prior tests — yet still found signals of unexplained
         thrust."

No, the EmDrive does not work, they just haven't yet figured out yet why they see the spurious acceleration in their measurements.

How do we know it doesn't work? Because it violates conservation of momentum, without involving any of the extreme conditions where our current understanding of physics might break down. Basic physics is REALLY REALLY well tested. The chances that some new experimental configuration will expose new physics, without involving extreme energy concentrations or extremely large or tiny spatial dimensions, is so near to zero as to be negligible.

<comment><USER7> Look, we KNOW that the sun revolves the earth and is affixed to a crystal sphere, like the planets. It's clear from all observations that this is the case. I mean, we understand epicycles perfectly, and they're due to the motion of the spheres. The chance that some crackpot would expose new physics and prove that the Earth orbits the Sun is so near to zero as to be negligible.

Your argument is the same as those made around relativity, as it disagreed with Newton, and what could some fucking patent clerk possibly know that the Greatest Scientist Ever didn't?

<comment><USER8> The people discounting Kepler and Einstein had actually read their work. They discounted it based on the lack of physical evidence(experimental results). People in Einstein's time were still confused and trying to understand the outcome of the Michaelson-Morley experiment. As for Kepler, he didn't provide any new evidence either. The only advantage to changing the center of the system was to eliminate the need to calculate epicycles when creating an ephemeris.

I could certainly see how both theories would have attracted some disbelief in their time. In Einstein's case, people started to accept SR when new experimental results came that only made sense if the speed of light were constant and the laws of physics were invariant in all inertial reference frames.

Why do we have to accept that something novel is happening in this case? Can you find any way to explain this effect with existing theory? More importantly, what would have to be changed to accommodate this phenomenon? Is it possible that the engineers are just measuring noise?

These are important questions that have to be answered.

</comment></comment></comment><comment><USER9> They didn't confirm anything. It was merely a rerun of tests with more of the potential background causes mitigated. It is going to require a lot more tests before someone like NASA unequivocally states that this works. Especially given that this device relies on physics we don't yet know about.

Worth reading here: [http://forum.nasaspaceflight.com/index.php?topic=38577.940](http://forum.nasaspaceflight.com/index.php?topic=38577.940)

<comment><USER10> Not much unlike the recent string of Bell tests. Closing one loophole after another until you can feel confident there's no other reasonable explanation left except a single one, the proof or invalidation of the theory you're trying to prove.

<comment><USER11> This is very different from the Bell inequalities.

The Bell inequalities is an easy to calculate result of quantum mechanic, the whole calculation is less than 1 page long. (It's not easy to discover, but once Bell discovered it, anyone can check the calculation.)

It follows the same rules of all the other QM experiments that have been thoughtfully tested, so it's totally expected to be true. The problem is that it's unintuitive, or to be more clear it's even more unintuitive that the usual QM results.

The loopholes were very weird, like:

"The PRNG of my computer is conspiring with the PRNG generator of your computer to get the results of the Bell inequality. They can conspire using signals that travel at less than the light speed, so perhaps we have conspiring hidden variables and not QM."

So to close the loophole someone has to use a real RNG instead of a PRNG, and be sure that it random. And do the measurements in a short time so the crystal in one site can't conspire with the crystal in the other site, and do the experiments far away so the light doesn't have enough time to travel from one sensor to the other sensor. The loopholes were totally paranoiac loopholes, but to disprove the hidden variables theories you have to close all the loopholes. (I think it's possible to imagine even more weird loopholes, so expect a few linkbait announcement in the next year with the discovery of an insane loophole in the last Bell experiment.)

The EM drive breaks the current accepted physics theories if the thrust/energy ratio if greater than 1/c = 3.33 nano-Newtons per Watt.

Some of the loopholes are:

The electromagnetic force between the wires in the device (it's like an electromagnet, without the iron core, so it's not as strong as a true electromagnet)

The force due to thermal effects, like expansion or convection, because the device get really hot when in use. Some of the experiments measure a delay that is expected when you need some time to heat the device and some time to cool the device after use.

The problem is that they still are closing the obvious loopholes, not the weird ones.

The usual trick is to have a very strong force that is much more than the expected effects of heating and electromagnetic interactions of the wires, but they have measured only a very tiny force.

<comment><USER12> The "Chaotic Ball" model,local realism and the Bell test loopholes

[http://arxiv.org/abs/quant-ph/0210150](http://arxiv.org/abs/quant-ph/0210150)

</comment></comment></comment></comment><comment><USER13> Why don't they just put one of these things in space, with solar panels, turn it on, and see what happens? I guess the expense? It does seem the most expedient way to verify whether it works or not.

<comment><USER14> even SpaceX launches cost over 50 million dollars ([https://www.google.com/search?q=spacex+launch+cost](https://www.google.com/search?q=spacex+launch+cost) has a big pullquote to that effect, for example)

</comment></comment><comment><USER15> A lot of skepticism and negativity here, and I get that. But it's exciting to watch science play out. This could be a huge discovery, or it could be crap. I love seeing the methodology in making each test more and more definitive by reducing variables and outside influences.

</comment><comment> stargazer-3 I love that the question of this technology's validity is so grand it can be approached with Fermi's Paradox. If such physics indeed exists, allowing interstellar expansion of life, then it increases our chances of detecting a signature of extraterrestrial life out there. Since we haven't detected anything yet, it seems that EmDrive-tech is less likely to be real than if we would have.

<comment><USER16> This technology doesn't make interstellar travel much easier, even if it works. You only save reaction mass, but you still need huge amounts of energy. Our best bet currently are nuclear pulse engines [1]. Super advanced civilizations might use Hawking radiation instead [2].

[1] [https://en.wikipedia.org/wiki/Project_Orion_(nuclear_propuls...](https://en.wikipedia.org/wiki/Project_Orion_\(nuclear_propulsion\))

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

</comment></comment><comment><USER17> Seems like they need to do the hardware equivalent of a "git bisect" here. Instead of fiddling around with the current version of the device, trying to figure out if the observed effect is actually propulsion or just an artifact, someone should start tearing the thing apart, testing as they go, and find out at what point the observed effect goes away. That would probably be instructive.

</comment><comment><USER18> Very interesting. I've been following this in the news for some time, hoping to learn the results of the latest research.

In previous tests it seemed like the significance of the effect was diminishing on each iteration, suggesting it might be experimental error. Anyone have a handle on how the latest results have changed? I don't get a good sense from the article.

<comment><USER9> The purpose was to reduce the Lorentz force interactions:

1) Built and installed a 2nd generation, closed face magnetic damper that reduced the stray magnetic fields in the vacuum chamber by at least an order of magnitude and any Lorentz force interactions it could produce.

2) Changed up the torque pendulum's grounding wire scheme and single point ground location to minimize ground loop current interactions with the remaining stray magnetic fields and unbalanced dc currents from the RF amplifier when its turned on. This reduced the Lorentz force interaction to less than 2 micro-Newton (uN) for the dummy load test.

3) Rebuilt the copper frustum test article so that it is now fully integrated with the RF VCO, PLL, 100W RF amp, dual directional coupler, 3-stub tuner and connecting coax cables, then mounted this integrated test article at the opposite end of the torque pendulum, as far away as possible from the 2nd generation magnetic damper where only the required counterbalance weights now reside.

Now since they were still seeing 100uN of force that means they have 98uN of force unaccounted for. And the next iteration of the test is trying to mitigate the effect of any thermal forces.

<comment><USER19> At which point it would be actually cheaper to put this whole thing in space, turn it on and see if it produces any trust? If it does, then it definitely works. As long as it's on Earth, they will spend forever trying to account for extra variables.

<comment><USER20> Yeah. The general rule of thumb is that it costs $10,000/pound to put something into orbit. The cost would increase by orders of magnitude once you include all of the other resources needed to track the experiment, but this does seem like a relatively cheap experiment to run in space.

[http://www.nasa.gov/centers/marshall/news/background/facts/a...](http://www.nasa.gov/centers/marshall/news/background/facts/astp.html_prt.htm)

I think what's preventing this is:

1.) NASA can only run a certain amount of experiments at once and I'm sure there's a long waiting list. If they run this one, something else doesn't run.

2.) Space may not be the extra variable-free environment we're hoping for here: tons of intense electromagnetic activity and so forth.

</comment></comment></comment></comment><comment><USER21> Can someone please explain to me how does one creates new technology without having alt least one of the following? a) working prototype, b) consistent theory why the new technology will work.

In other words, what made Roger Shawyer believe his engine will work if he does not know how should it work nor have a prototype?

</comment><comment><USER22> So if an EmDrive worked, what would it give us? A star trek impulse drive type thing? Or is it so low level an effect it would be useless?

<comment><USER23> The impulse engine in Star Trek was just a fancy fusion-powered plasma rocket.

[http://memory-alpha.wikia.com/wiki/Impulse_drive](http://memory- alpha.wikia.com/wiki/Impulse_drive)

<comment><USER24> Actually, there are several in-universe articles saying otherwise:

The interaction between the shields and a conventional propulsive system would be horrible (you'd get fried in your own plasma).

Therefore the Interacting Magnetic Pulse system (sorry, I'm translating back here, so I dunno if that's the correct term in the correct in-universe article in english) actually uses some weird interaction of microwaves to create "gravitational waves on which the ship then rides", as one engineer said poetically.

</comment></comment></comment><comment><USER25> Economical crisis are recognizable by the fact people tends to announce "infinite energy source", "cheap energy", or "perpetual movement" finally made true.

It is very interesting that while NASA that has been a clear "cache nez" during cold war to mask the use of nazis scientists and technologies for the USA they are now having a problem: space programs are considered to costly for their return other investment. Especially when you know the budget of ESA for rosetta/philae mission compared to NASA's budget.

Being on the grill, NASA is lobbying for even more costly mission to mars and support their own propaganda (intestallar, alone on mars...).

And now, miracle, they have an opportunistic new technology that could help achieve "cheap easy journey" to far away distance.

I can't help to be a little suspicious. The timing is so perfect.

And as numerous comments are spotting there is no new technology until we can explain the causation. Because that is how science work: experiments should be consistent with theory, and vice-versa. Else this is religion or philosophy.

Maybe emDriver could be the proof God exists, but it is not likely. Well, if it existed, and since we would have a physical place where to search I would kill it anyway. I hate Gods, I prefer to drive my own destiny without a "père/mère fouettard(e)" looking upon my shoulder like a stalker.

</comment><comment><USER26> Woo hoo! The reactionless thruster! Next: Outsider hyperdrive!

[http://news.larryniven.net/concordance/main.asp?alpha=T#thru...](http://news.larryniven.net/concordance/main.asp?alpha=T#thruster)

</comment><comment><USER27> I almost want to flag this link for playing loud sound advertisements on page load, but I'm not sure that's proper in this community. Is there not a better link to this content?

</comment><comment><USER28> Previous discussion: [https://news.ycombinator.com/item?id=10496638](https://news.ycombinator.com/item?id=10496638)

</comment><comment><USER29> I'd really like to see @dang et all at HN add digitaltrends.com to the penalised-by-default domains on HN. This is simply irresponsible hackery.

Rick Stella as well.

</comment><comment><USER30> Momentum has velocity, but the velocity of light is the same in all reference frames. It seems like there is a conflict between conservation of momentum and special relativity. From the point of view of the light beam, nothing is moving.

<comment><USER31> The speed of light in a vacuum is constant in all reference frames, but a photon's frequency is _not_ constant in all reference frames, so it's momentum (hf/c) is not constant.

This is bog-standard special relativity.

<comment><USER30> Ah, this makes sense.

</comment></comment></comment><comment><USER32> Cold fusion is the power source too.

</comment><comment><USER33> Caution is called for. After all, blowing past warp 5 can damage the space- time continuum.

</comment><comment><USER34> I can't name sources, but I have it in good confidence that this man ("Sonny" White) was forced to rewrite his dissertation by his PhD committee (mind you not his advisor, who was old and about to retire and had to be cajoled into line by the rest of them) because his first try was apparently all about this EMDrive stuff. This is a pathology.

<comment><USER34> So, I'm being down voted for stating a relevant fact? I was asked not to reveal this by my source.

<comment><USER35> For stating irrelevant hearsay, perhaps.

<comment><USER34> What, and if I break confidence and name names from the Rice faculty that would somehow be better?

Being forced to rewrite entirely at a defense by the rest of one's committee is a BFD, it absolutely impacts his credibility.

<comment><USER35> Without knowing the details of what happened, we have no idea how it affects this person's credibility.

 _You_ have no credibility, so your unverifiable story conveys zero information. All it does is stir things up. Substantiating the story would be good, and failing that, saying nothing would be better than essentially spreading a rumor.

<comment><USER34> I'm a physics grad student at a university not too far from Rice. How am I supposed to substantiate this short of producing the first draft of his PhD thesis? Do you think academia keeps these things around?

<comment><USER35> It doesn't sound like you can substantiate it. But that has no influence on your credibility, or on the believability or relevance of what you're saying. From the outside, a true story that inherently can't be substantiated is indistinguishable from a made-up story that can't be substantiated. And it doesn't even have to be you who made it up, it could be the person you got it from, or wherever _they_ got it, or all the way up the chain. Or maybe it's true! I have no idea, which is why I called it "hearsay" instead of "lies."</comment></comment></comment></comment></comment></comment></comment>


Rack::SpellCheck - Any Rubyist want to build it into a Gem with me? - <AUTHOR> https://gist.github.com/1944060

<comment><USER2> I might take a shot at it tonight or tomorrow. I have been meaning to learn how to build stuff like this into Gems...

<comment><AUTHOR> Hey! I know how to build out Gems no problem, there are a few things beyond that I could just use another set of hands with:

      * Testing!
      * Railties. If you include it as a Gem in Rails, it should add itself to Rack, etc.
      * Gemspec, Rake tasks etc.

I've done all this before, but it would be more fun to build it out with somebody else. Down with it? email@example.com</comment></comment>


Uncap – Map Caps Lock to Escape (Windows, Linux, macOS) - <AUTHOR> https://github.com/susam/uncap/blob/master/README.md#alternatives <comment><USER2> Is the utility of this that Caps Lock is much closer to the home row (on a QWERTY keyboard) than ESC? Now that I imagine it, I am a (Neo)Vim user and so pinky-ing over to CAPS instead of ESC would be a time-saver for sure.</comment>


Some people see this dress as white and gold while others see black and blue - <AUTHOR> http://sploid.gizmodo.com/some-people-see-this-dress-as-white-gold-while-others-1688330144

<comment><AUTHOR> Here's the most reasonable explanation I've heard:

[https://twitter.com/andyrexford/status/571118728164872192/ph...](https://twitter.com/andyrexford/status/571118728164872192/photo/1)

</comment><comment><USER2> I looked at this on my iphone, in front of a window at sunset and it was clearly white and gold. I adjusted the brightness settings on my phone and saw no difference.

Now I'm looking at it under florescent lights, and on my computer and iphone it's clearly black and blue. Wow.

</comment><comment><USER3> Do those people who see it as black and blue have color blindness of some kind? It's quite clearly brown and blue-gray to me. The eye dropper in Paint.Net says the same thing. Not sure how anyone can get black out of this.

<comment><USER4> The black and blue camp is actually closest to what you see. The differing opinion are those who see it as white and gold.

<comment><USER5> I see black & blue as well .. but apparently not according to gawker ... their poll has white&gold winning it at 76%

[http://gawker.com/what-color-is-this-goddamn- dress-168833017...](http://gawker.com/what-color-is-this-goddamn- dress-1688330170)

<comment><USER6> I saw white and gold the first time I saw the image, and blue and black the second...

</comment></comment></comment></comment><comment><USER7> Y'all must have some really whacky device settings or poor eyesight because I can't _not_ see blue and black no matter what device/browser I look at it with or under what conditions.

<comment><USER8> So do you see the light part of the dress as white? If so, what colors are the cow-print looking clothing just behind this one on the left?

</comment></comment><comment><USER9> Any one else saw blue and gold? FWIW I'm viewing on an ipad.

<comment><USER10> I see it as very light blue and as gold. From an eye dropper chrome extension this seems to be the correct color of the photo.

The white or blue part appears to be #8292b3. And the gold or black part appears to be #7b6d48.

[http://www.colorpicker.com/8292b3](http://www.colorpicker.com/8292b3)

[http://www.colorpicker.com/7b6d48](http://www.colorpicker.com/7b6d48)

I think out of the photo people will agree these are blue/gold.</comment></comment>