Discourse ditches CoffeeScript - <AUTHOR> http://meta.discourse.org/t/is-it-better-for-discourse-to-use-javascript-or-coffeescript/3153 <comment><USER2> If you understand programming (there is a difference between knowing how to program and understanding, a lot of people lack the latter) there is absolutely no difficulty learning CS if you know JS.

I've been coding CS for over a year now and I like it, I've never found it hard to debug and it's just easier to read.

<comment><USER3> CoffeeScript's scoping is broken. [http://lucumr.pocoo.org/2011/12/22/implicit-scoping-in- coffe...](http://lucumr.pocoo.org/2011/12/22/implicit-scoping-in- coffeescript/)

<comment><USER4> I greatly prefer Scheme-like lexical scoping. However, JavaScript does not implement lexical scoping properly. Given the particularities of JavaScript's inadequacies, I think that the CoffeeScript design is very reasonable. It's certainly not "broken".

Lots more discussion here: <https://news.ycombinator.com/item?id=3379962>

<comment><USER5> Um... I believe JS does have proper lexical scoping. Could you source any evidence to the contrary?

<comment><USER4> JavaScript's lexical scoping is function-level. There is no block level lexical scoping, so variables are "hoisted" to the containing scope. This is why people use the (function(foo){...})(bar) trick to create lexical scopes, such as when looping (CoffeeScript's `do` keyword embodies this pattern). In my opinion, "proper" lexical scope implies shadowing without hoisting.

<comment><USER6> If you understand hoisting as a characteristic of JavaScript, its behavior is very predictable, and thus, hardly broken -- merely tricky if you've yet to encounter a hoisting-related issue.

That said, I find almost any issue with writing JavaScript can be easily mitigated by utilizing JSHint, and you get the added benefit of sticking with the base language, which is better because if you're writing raw JS everyday, your skills are more transferable than if you're writing CS every day if only for the fact that you can still write JS in a CS-only stack, but you can't write CS in a JS-only stack.

</comment></comment></comment></comment></comment></comment><comment><USER7> Did they? I can't get to the end of the thread 'cause their infinite scroll thing is not working on mobile safari. Looks like they should focus on coding instead.

<comment><USER8> our mobile story sucks at the moment, we are dying for a mobile friendly skin at the bare minimum, contributions totally welcome.

you can get it to work on mobile safari in portrait if you zoom in / out ... but that just too hacky

<comment><USER9> Your web-site also sat with the spinner running for 4+ seconds.

You might want to try providing it in HTML format.

</comment></comment></comment><comment><USER10> I find this a curious debate to have so early in Discourse's life. There doesn't appear to be a pain point, so it's mostly speculation. If this happens, then that consequence, but if this happens, then that other consequence...

I would stick with CoffeeScript until it becomes painful. There is relatively little downside risk. If and when you have great people refusing to contribute code because they hate CoffeeScript, well, that'll be a pain point. On the other hand, what if you get a bunch of other people who like contributing code because they can do it in CoffeeScript?

Are there meaningful statistics collected? Until there are, or at least a weighty collection of anecdotes, I'm sure there's something more important to worry about.

<comment><USER11> Disclaimer: I don't know Discourse's situation in detail, and I use CoffeeScript on node.js, not the client.

The sheer mass of anti-CoffeeScript FUD ironically makes it more likely that they'll get more contributions if they go back to JavaScript. ;) YOU might know people who seriously consider Erlang and Clojure, but most people respond badly to superficial syntactical differences.

Of course, is "contributions" really the best metric? What about productivity or quality? And can they make it so that people can easily contribute JavaScript?

(Even among people I know, I've heard such irrational FUD against CoffeeScript. And I know it's FUD because none of their boogiemen came true after I aggressively introduced it into their codebase. They now use it every day without concern. Most people hate innovation, including programmers.)

In particular, the ES6 argument sounds like FUD. Did they link to timelines and CoffeeScript developers' opinions? And where's the tradeoff analysis comparing the immediate productivity benefits of CoffeeScript vs some future ES6 event?

</comment></comment><comment><USER12> Am I the only one that has trouble parsing this CoffeeScript? I thought the syntax was suppose to be cleaner than plain javascript:

MyApp.president = Ember.Object.create fullName: (-> @get('firstName') + ' ' + @get('lastName') ).property('firstName', 'lastName')

How the hell am I suppose to read that?

<comment><USER13> If you were to read the equivalent javascript as a one liner it would be hard to read too. Probably more so. Really, all you are pointing out is that you can write shitty code in any language. No language protects you.

If you write beautiful javascript, you will write beautiful coffeescript and it will be 20-60% smaller. Reading less lines is less reading, this helps me.

<comment><USER14> Nonsense. The equivalent JavaScript is clearer, albeit more verbose.

<comment><USER13> Neither is very palatable.

MyApp.president = Ember.Object.create(({fullName: (function() {return this.get('firstName')+' '+this.get('lastName');}).property('firstName', 'lastName')}));

MyApp.president = Ember.Object.create fullName: (-> @get('firstName') + ' ' + @get('lastName') ).property('firstName', 'lastName')

<comment><USER14> At least I can look at the first one and it's more obvious to me what it does. The braces help.

</comment></comment></comment></comment></comment><comment><USER15> If I've understood correctly, the most compelling argument (or at least the most seemingly objective one) is that CoffeeScript conflicts with planned features of ES6+, meaning that there is a risk that large CoffeeScript projects will be locked into the ES5 feature set.

Since Discourse is planning on being around long after ES6 becomes widely available, it was a winning argument.

[http://meta.discourse.org/t/is-it-better-for-discourse-to- us...](http://meta.discourse.org/t/is-it-better-for-discourse-to-use- javascript-or-coffeescript/3153/19)

Also, one of the big reasons the Discourse devs liked CoffeeScript is because it makes it hard to commit common JS errors. Building JSHint into their workflow can help bring this protection back.

<comment><USER16> Seems like a very narrow mindset. Why would they assume coffeescript won't adapt to ES6? CoffeeScript compiler can change quickly while maintaining backwards compatibility. ES6 standards move at a snails pace.

There's other perfectly valid reasons to use pure-JS on a large open source project, but the ES6 thing is a red herring IMHO.

<comment><USER17> What makes you think CoffeeScript can target ES6 while maintaining backwards compatibility? Did you read the discussion? Wycats makes a very good argument for the opposite position.

<comment><USER16> Yep, I did read the discussion. I think wycats brings up a perfectly good concern, but the key point which he misses is that there is time, and CoffeeScript can change to fix what I think is a very solvable issue.

The current estimate for ES6 support in browsers is 2014. CoffeeScript only hit 1.0 about 2 years ago, and has had 3 minor point releases since then.

For me it's not hard to imagine a CoffeeScript 2.0 release at some point next year that targets ES6. It could make a few syntax changes, and ship with some helper tools (or a 3rd would create it) to detect possibilities in your previous code and tell you where you need to tweak to make it compatible.

<comment><USER17> So, basically, CoffeeScript _can't_ target ES6 while maintaining backwards compatibility, but it doesn't matter, because they have time to manage the transition. Ok, that may well be.

Personally, I agree that ES6 isn't that big an issue, but for a different reason: when they decide they want to take advantage of ES6, they can always make the switch to Javascript _then_ ; there's no reason it has to happen now.

<comment><USER18> _CoffeeScript can't target ES6 while maintaining backwards compatibility_

Is that really true? I mean, it is not as if JavaScript is a _subset_ of CoffeeScript. [1]

It seems to me that the worst case scenario here (for CoffeeScript) isn't backward incompatibility, it is drifting further away from the JavaScript syntax/grammar than one might like. Take the `for/of` concern raised in the thread. Why would CoffeeScript _need_ to change its semantics to match that of ES6? ES6 could introduce a new and different meaning of `for` and `of` (whatever that is) but CoffeeScript could keep its meaning for `for` and `of` (whatever that is). The problem, if any, will be in "wetware".

Isn't the analogy here something like

 _CoffeeScript is to JavaScript as Closure is to the JVM_.

Does Closure break if the JVM adds new features? Why would we expect CoffeeScript to?

[1] Excepting the back-tick delimited escaping for literal JavaScript, but that's not an issue here.

<comment><USER17> Because of the 1JS principle, ES6 will be a strict superset of ES5. CoffeeScript can maintain its existing semantics, produce the same JS output that it does now, and nothing will break. But then it's not really targeting ES6, is it? It's targeting ES5 and benefitting, as all Javascript code does, from ES6's backward compatibility with ES5.

So sure, if we're not interested in the new features of ES6 in the first place, then I grant that ES6 compatibility is a red herring.

<comment><USER18> To be candid I don't know the details of what is changed in ES6. Is there a specific aspect of ES6 you're thinking of?

But the new features of ES6 aren't features of CoffeeScript. Why would we expect them to be?

It's like noting that Java 7 adds support for strings to switch statements and wondering how the syntax of Closure is going to change in response.

There is no strict requirement for the languages to be tied together at a syntax level, they just "compile" to something compatible.

There may be strong technical reasons for the CoffeeScript _compiler_ to take advantage of the new features of ES6, but that doesn't force a change to CoffeeScript-the-language. (In other words, it _can_ target ES6 while remaining backward compatible.)

I wouldn't be surprised to discover I'm missing something, but I'm genuinely confused why this is seen as a technical problem. It's not that CoffeeScript- the-language is "not interested in the new features of ES6", but that, technically speaking, CoffeeScript-the-language is not interested in ES-the- language at all.

Apples and oranges. (Or maybe lemons and limes.)

As an aside, I _do_ see this as a potential social problem. CoffeeScript would probably like to remain conceptually-compatible with JavaScript, and that gets much harder if the two have different semantics for similar syntax-es, but I'm going to guess this isn't the only example of it.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> > CoffeeScript has significant whitespace. So instant no. It makes it a pain > in the butt to parse. It's annoying. Most people (except for Python > developers) don't like it. Due to being difficult to parse, you will have > problems when you try to refactor. Not to mention the problems of re- > indenting everything when you have really long and ugly blocks you want to > clean up (happens).

maybe people should stop writing unindented ugly blocks in their non-indent- significant language then?

<comment><USER20> No one is writing un-indented code. The issue is lack of metadata for automatic indentation.

In C if I shift a block of code a quick gg=G will reformat and reindent. Possible because blocks are explicit and whitespace is separate from scope. By the same token autogeneration of {}'s is impossible in C. This is obvious but obfuscated in Python from whitespaces' overloading.

The issue is autogeneration of blocks. In any language blocks are a fundamental aspect of programming. Blocks affect the function of a program. Since we lack self-programming computers we also lack autogeneration of blocks. Python's issue is that a non-fundamental aspect of programming has been paired with a fundamental aspect of programming.

<comment><USER21> >Python's issue is that a non-fundamental aspect of programming has been paired with a fundamental aspect of programming.

Python's "issue" is that it considers readability as a fundamental aspect of programming and that whitespace is critical to that end. Whether that suits a particular programmer is a matter of personal preference.

</comment></comment></comment><comment><USER22> Is it just me or is anyone else finding it weird viewing a thread on Discourse from HN? It's basically the same thing IMO (although obviously this is a Discourse site announcement). I just hope this doesn't become a "thing" as it's just essentially same as linking to a forum post.

<comment><USER23> I just thought it was a way for the Discourse guys to get people here to look at a 'real' thread in Discourse to get a feel for the system. If it is compelling enough to get someone to register and comment its a double benefit.

That said, the annoying ones for me are links to Google+ things, the URL says "google.com" but the content is various.

<comment><USER24> That's one of the very few things HN should borrow from reddit: use subdomains in the URLs, so we could see (for example) that it's from plus.google.com.

</comment></comment></comment><comment><USER25> History repeats itself. This topic reminds me of QWERTY vs. Dvorak. People continue using something because everyone else is and they always have; not because it's the optimal option.

<comment><USER26> There's no proof Dvorak is any better. <http://www.reason.com/news/show/29944.html>

<comment><USER27> Wrong.

"First, Dvorak is very good at keeping fingers on home row - 71% of keystrokes land there (compare this with 34% for QWERTY). This alone is worth the price of admission. Dvorak bottom row usage is very low at 9% (15% for QWERTY). Dvorak favours the right hand by 14% (QWERTY favours left by 15%). Dvorak has more uniform finger usage and makes greater use of the pinky (18% vs QWERTY's 10%). The cumulative run statistics illustrate Dvorak's strength in alternating hands. 62% of successive keystrokes on Dvorak do not use the same hand (rh(0)) and 88% of adjacent keystrokes use the same hand at most once (rh(1)). In contrast, with QWERTY only 51% of successive keystrokes do not use the same hand and only 76% use the same hand at most once. QWERTY forces the typist to use the same hand repeatedly, which limits the amount of rest and increases effort. Dvorak's preference for the use of the right-hand give it longer right hand runs with only 47% of keystrokes that use the right hand being followed by use of the left hand (61% for QWERTY). The corresponding statistic for the left hand is reversed, with Dvorak at 76% and QWERTY at 42%."[1]

The authors of the Reason Magazine article from 1996 that you linked to stated that "Ergonomic studies also confirm that the advantages of Dvorak are either small or nonexistent." But the authors cited only one nameless, undated study. This promotion of QWERTY isn't surprising seeing as how Reason Magazine is written by ideologues whose goals include the promotion of the idea that the invisible hand of the market is never wrong.

You should consider getting your information from specialists who are active researchers rather than the writings of non-specialists from previous decades.

[1] <http://mkweb.bcgsc.ca/carpalx/?dvorak>

<comment><USER26> You should take a look at the research behind Colemak (and a less known layout named Workman), to see that Dvorak is a subpar layout, with misguided reasoning and poor optimisations.

</comment></comment></comment></comment><comment><USER28> I supported the switch to JavaScript, despite being an avid Coffeescript developer. Why? Because any CoffeeScript developer worth their salt already knows JavaScript, and can translate the JS to CS and back quite simply (admittedly, it's not as nice as hand-written CS, and the compilation loses comments, but I still prefer it to writing the JS by hand if I'm doing a bunch). But many, many JS developers don't know CS, or don't like it.

Now, this only affects the first official client. I imagine that there will be a CS port of the JS client as soon as the switch is made. That's the great thing about using a client to a REST API - you can have several different front-ends. If this was to be the only client, I'm not sure if I would support using JS over CS.

(btw, I'm @benaiah on meta.discourse.org - I'm in the referenced thread)

</comment><comment><USER29> I think the advantage of this project being open source becomes really clear in situations like this: I'd imagine js2coffee[1] will cover most of their bases, but in the situation that it _doesn't_ , they have a (pretty active) Github community to fall back on for the finicky bits of conversion.

[1]: <http://js2coffee.org/>

<comment><USER30> It's been a while since I looked at js2coffee, it's nice that they've eventually fixed the lack of transferring comments issue.

</comment></comment><comment><USER31> I would discuss how I feel about coffeescript and interstitial white space sensitivity and the ilk, but I'll point to a blog post which expresses most of my views neatly: [http://blog.izs.me/post/10213512387/javascript-is-not-web- as...](http://blog.izs.me/post/10213512387/javascript-is-not-web-assembly)

</comment><comment><USER32> I've found that CoffeeScript is great at standardizing the various styles of coding JavaScript that exist in an office.

</comment><comment><USER33> good..now i will look into Discourse...

</comment><comment><USER34> I developped a little layout library ( work in progress ) which is a port of a flash lib. and frankly coffeescript made it really easy and made me wrote far less code that pure javascript.

One can write readable code with Coffeescript , i use parenthesis in big scripts because it is more readable , and i dont use classes where not appropriate.

CS helped me write better javascript without the badparts so i dont need to be a human compilator and fix javascript each time i write it. I should not have to.

<http://mparaiso.github.com/Coordinates.js/>

It is not for everyone , but significant white spaces are not a problem if one is used to indent his code properly. I tried typescript too , which is good, but i found coffeescript more expressive. The truth is , i enjoy writing CS , i dont writing JS.</comment>


Ning - Create Your Own Social Network for Anything - <AUTHOR> http://www.ning.com/ <comment><AUTHOR> I know they are receiving a lot of press already, but I just think that a website that allows users to make a social website that allows users to contribute amusing. Wonder if someone can take it to the next level: make a webiste that allows users to make websites that allow users to make more specific niche websites that have user contributions for content, haha.

<comment><USER2> That's what PHP/MySQL are for. ;-)

<comment><AUTHOR> hehe, i was thinking the same thing when I wrote that :-)</comment></comment></comment>


Supreme Court says government needed warrant to search cellphone tower records - <AUTHOR> https://www.washingtonpost.com/news/technology/wp/2018/06/22/supreme-court-says-government-needed-warrant-to-search-cellphone-tower-records/ <comment><USER2> Duplicate. The top post right now.

[https://news.ycombinator.com/item?id=17374440](https://news.ycombinator.com/item?id=17374440)

</comment><comment><USER3> This case presents a very interesting look at the different methods of Constitutional analysis. The gist of the majority's reasoning is that under _Katz_ (the applicable precedent addressing the scope of the Fourth Amendment), what matters is that someone has a "reasonable" expectation of privacy in the subject of the search. _Katz_ takes a classically functional approach to the question: it looks at (the Justices' conception of) what problem the text was trying to solve, and interprets the text in that context. It concludes that location data is protected because people reasonably expect that their whereabouts from cell tracking will be kept private.

The dissent takes a textual approach. It points out that the Constitutional text says nothing about "expectations of privacy" but rather protect's a specific person's property: It protects the "right of the people to be secure in _their_ persons, houses, papers, and effects, against unreasonable searches and seizures." As Justice Thomas points out, it is undisputed that the cell phone records do not _belong_ to the individual. Cell phone records are information _about_ people, not "their" information. (Just like all of the records, Google, Facebook, etc., have _about you_ remain Google, Facebook, etc.'s private property, not yours).

This case eviscerates third party doctrine. Third party doctrine can often be described in a _Katz_ formulation (one cannot have a "reasonable" expectation of privacy in information you have chosen to share with third parties). But more deeply, it reflects the basic textual restriction in the Fourth Amendment to protecting things that are _yours_ (not _about you_ ). It'll have major ramifications for similar searches directed at companies like Google, Facebook, etc., and may result in courts determining that warrants are required for such data requests as well.

</comment><comment><AUTHOR> Here is the opinion: [https://www.supremecourt.gov/opinions/17pdf/16-402_h315.pdf](https://www.supremecourt.gov/opinions/17pdf/16-402_h315.pdf)</comment>


A simple tool that turns a pure Python package into a single executable. - <AUTHOR> https://github.com/brownhead/superzippy <comment><AUTHOR> This tool is similar to others like PyInstaller and cx_Freeze. It uses a simpler algorithm and is a lot easier to use thanks to the fact that it doesn't try to deal with non-Python dependencies.

There's a video of me demoing the project in my portfolio at [http://johnsullivan.name/projects.htm#superzippy](http://johnsullivan.name/projects.htm#superzippy)</comment>


Ask HN: What is iOS's biggest security risk? - <AUTHOR> What's in your opinion the biggest security flaw / risk in iOS devices that is exploitable to either read your local data from apps, or spy on users. without starting a debate war, is Android safer and why ?<p>reflecting back on San Bernardino on how the FBI made a big fuss about apple refusing to give access and how so easily things got buried under the carpet as soon as the FBI "found another way" around it, everyone seemed to be relieved. My question is what security flaw did the company the FBI hired exploit and what would you do if you were at apple to prevent it ? <comment><USER2> A Typical strategy for breaking into a phone with no time limit is to simply wait until updates get published, examine what was fixed, and exploit the unpatched version of the phone. This is likely what happened in the FBI case you noted as there were a number of updates of ios9 published during that time. While iPhones are typically regarded as secure, the main problem with ios is that the source is closed and thus more likely to contain zero days.</comment>


Rust vs. Ruby: building an API - <AUTHOR> http://serdardogruyol.com/rust-vs-ruby-building-an-api/

<comment><USER2> > Update: I've reproduced the Ruby benchmarks with RACK_ENV=production > variable and saw more than 5x performance increase.</comment>


Small Bank in Kansas Is a Financial Testing Ground - <AUTHOR> http://dealbook.nytimes.com/2014/12/13/small-bank-in-kansas-is-a-financial-testing-ground <comment><USER2> > In the coming weeks, it is expecting to roll out what it refers to as a bank > account of the future, which will make it possible to send wire payments and > create customized debit cards online.

Or at least a bank account of a normal European bank. At least for the moving money part. I can do that easily and with no fees here in Italy, which isn't the leading light of banking it was 600 years ago.

Hopefully that kind of thing will finally take off in the US. I wonder what the difference is:

> But hastening the movement of money creates risk for banks, because it > generally means less time to catch fraudulent transactions.

That's got to be a risk in Europe, too, no? How is it dealt with differently?

<comment><USER3> > _How is it dealt with differently?_

I can't speak for Europe. I once griped about the slowness of US banking to an Australian acquaintance who worked in banking technology in Australia and Britain. Here follows my half-remembered, probably inaccurate understanding.

In Australia, a bank has a very high confidence of that a transfer is going from real, physical person A to real, physical person B.

This is because of the "100 Point" identity check you need to perform when you open account. To open a bank account, you need to present multiple, independent forms of ID, including at least a driver's licence or a passport and some identification showing your current residential address.

It can absolutely be circumvented, but the bar for doing so is significantly higher than casual small-time fraudsters are interested in.

In the USA, I can find a small-town bank who will open my account without looking at me too closely, then start issuing dodgy cheques much more easily. In Australia, _no matter where I go_ , I will be required to prove that I am who I say I am. So the ability for banks or police to lay hands on me or my money is significantly strengthened, and consequently the rate of fraud is lower.

I see this also with online shopping. In Australia I never once, in my entire life, had a credit card purchase rejected. In the USA my Bank of America card regularly locks up and waits until I login to assure them that it hasn't been stolen.

</comment></comment><comment><USER4> "His first discovery was that nearly all banks rely on a few big, and not terribly agile, outside vendors to provide all the software that makes bank computer systems work."

I worked in this industry for about 6 years in the 90s, and there were a few small companies moving all the data center functions over to pc software from mainframes, but most (all?) of them got bought up by the big players. I got out of it when the medium-ish company I worked for got bought up and I got laid off. I heard some of the people I worked with split off and started new tiny companies.

Circle Of Life, I guess.

<comment><USER5> From what I've in the finance industry, there aren't enough standards.

It seems like every bank/broker/data provider stores and sends data in its own format and has different procedures for clearing. It's like the priority is to make sure people can't switch easily.

</comment></comment><comment><USER6> Wow, this is actually some real innovation in a stagnant industry that actually affects millions. (And it's in the part of the country commonly written off)

This is far more interesting/inspiring and has a much greater impact on the world than the 'break stuff and ignore laws' mentality of Uber and similar Silicon Valley darlings.

<comment><USER7> Interestingly, Django also came out of Kansas :)

<comment><USER8> Yantra is actually located in the small town where django was created (lawrence)

<comment><USER9> Not that small. Lawrence is the home of the University of Kansas.

I've lived all over the country, and Lawrence would rank towards the top for me. It's much like Austin, only smaller and less expensive. And probably more relaxed. The only drawback is that it's surrounded by Kansas.

<comment><USER4> Yeah, Lawrence is very much a cool college town. Reminded me a lot of Athens, GA.

On another note about Kansas, I was driving from Kansas City to Wichita on a daytrip with my girlfriend at the time. Like 1995, I think. We stopped in a small town along the way and for some reason found ourselves in this dress shop in a strip mall. It turned out to be a boutique type place, with the dresses at 300-400 each. Weird. Who would have thought they had a market there? Cattle and oil money, I guess.

That store also had a small collection of cassette tapes of Turkish pop music for sale, totally randomly. I bought them all.

</comment></comment></comment></comment></comment><comment><USER10> The assertion big banks aren't trying to innovate payments because we are in a "risk averse" period after the housing crisis is a stretch. I'm not sure if that's something the author concluded or an argument banks are actually using.

Mortgage loan risks were motivated mostly by greed. Improving money transfer systems would carry the risk of fraud, with a very long-term payout of improving customer experience. Bank CEOs nowadays want there quick buck and then parachute into retirement. There's no incentive for long-term thinking. And if you're dissatisfied where are you going to go? Another mega-bank with the same incentives...

Seeing as how banks just used their lobbying power to cripple Dodd-Frank, the argument "regulations get in the way of innovation" also hard to believe. When regulations got in the way of highly lucrative derivatives sales, it seems the banks were able to overcome.

I really hope these small guys can make a major impact.

</comment><comment><USER11> Really interesting story. I'd send the guy a resume if I thought I could get my wife to move to Kansas.

<comment><USER8> Well, if you're in SF you could show her the 7 bedroom mansion you could buy in Kansas for the price of a one bedroom in the mission.

<comment><USER12> Doesn't matter how nice the house is, you're still living in Kansas.

</comment></comment></comment><comment><USER13> A bank in Germany has just one employee. [http://www.rediff.com/business/slide-show/slide- show-1-a-ban...](http://www.rediff.com/business/slide-show/slide- show-1-a-bank-in-germany-has-just-one-employee/20130215.htm)

</comment><comment><USER14> These guys actually do the back-end / debit card issuing for Moven Bank.

</comment><comment><USER15> If this area is of interest you should also check out[https://karmiclabs.com](https://karmiclabs.com). I have no relationship with the company but the founders are friends and think they are doing some really interesting things in the payment and debit card space.</comment>


Rapportive (YC S10) Has Been Acquired By LinkedIn - <AUTHOR> http://blog.rapportive.com/rapportive-acquired-by-linkedin <comment><USER2> Rapporative is such a fundamental part of how I get work done that I often forget that it isn't just part of GMail.

While I am really excited that these guys had an exit -- founders who make really great products deserve to get paid -- I hope that this doesn't mean that Rapporative will eventually be shut down or merged with LinkedIn in some horrible way that removes it from my inbox. I'm not sure if I can keep people straight without it.

<comment><USER3> Care to share how you use Rapportive to get work done?

<comment><USER2> When I go to startup events I frequently encounter people who know me that I can't remember ever meeting. When that happens, if my wife is with me she will discreetly remind me, "She's the technical founder of such-and-such." You see, I'm terrible with both faces AND names.

Rapporative does the same thing, but in my inbox.

</comment></comment></comment><comment><USER4> Congratulations to Rahul, Martin, Sam and all the others. As expressed by others I hope Rapportive continues independently in terms of account creation.

I really liked when Conrad from the support them explained an issue I had regarding merged accounts by providing the following graph, I did mention that I was a CS Major (hope the spacing lines up):

      firstname.lastname@example.com (user, merged) <--.
       |                                         \
        `-> firstname.lastname@example.com (user, merged) \
             |                                    |
              `-> email@example.com (user, merged)
                   |
                    `-> email@example.com (user)
                         |
                         |`-> email@example.com
                         |
                         |`-> firstname.lastname@example.com
                         |
                          `-> firstname.lastname@example.com

<comment><USER5> Smart tree design. Good character choices for branches.

First time I remember seeing that style. Now I wanna read more text-tree graphing everywhere.

<comment><USER6> man tree :)

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

_edit_ : Admittedly, the tense of the headline was different.

</comment><comment><USER8> This is probably the sweet spot exit that most entrepreneurs dream of ...

$1 million raised, 2 years of work and $15 million cash exit. The founders have obviously done very well in this exit.

Great story. Great product. Well done!

<comment><USER9> \+ n years of lockup.

<comment><USER8> Its cash.

<comment><USER9> So what? You can have a cash payout that takes time.

</comment></comment></comment></comment><comment><USER10> I find myself talking about Rapportive a lot as one of the better executed examples of the contextual delivery of relevant content. Glad these pioneers got rewarded for their work.

</comment><comment><USER11> Will Rapportive to continue to operate separately or become a specifically LinkedIn product?

<comment><AUTHOR> Not sure I understand what you mean by the difference?

<comment><USER12> Often acquisitions are done for talent more than product. Other times its because the company being acquired fills out a need for the parent company that they can't or don't want to fill internally. i.e. Why spend resources developing a competing product internally when you can add another company that does it better. So its a legitimate question that deserves an answer to Rapportive customers.

</comment></comment></comment><comment><USER13> Welcome to LinkedIn guys! Looking forward to meeting in person.

<comment><AUTHOR> thanks Diego! looking forward to it, to put it mildly :)

<comment><USER14> I double the welcome! Love the product and glad to have you as part of the team

<comment><AUTHOR> Hello Luke, and thank you! Can't wait to be there :)

</comment></comment></comment></comment><comment><USER15> Congrats Rahul, Martin, Sam and team! Do your Rapportive profiles reflect this news? ;)

</comment><comment><USER16> Thank goodness it's going to continue to exist!

<comment><USER17> But will it continue to be updated?

</comment></comment><comment><USER18> Congrats, this is a great tool which has often surprised me with the results it comes up with.

I'm very envious of your success. Looking forward to running into you guys one day, like you said, its a small world.

</comment><comment><USER19> Congratulations, Rahul, Martin, and Sam! This is great news. :)

<comment><USER20> and Lee!

<comment><USER19> and Conrad, while we're at it. :)

</comment></comment></comment><comment><USER21> Congrats Rahul, Martin! I've always been impressed by your quick responses to any issues via email.

What are your next steps?

<comment><AUTHOR> Make you brilliant with people — as simple as ;)

</comment></comment><comment><USER22> Congrats! It's a great product and Rahul is a really smart guy (as I'm sure the rest of the team is)

</comment><comment><USER23> Very cool. Rapportive is a great product. Well done to the team for a well- deserved acquisition.

</comment><comment><USER24> Rahul, Martin, Conrad, and others, Many Congrats! Rapportive is a really great product.

</comment><comment><USER25> Great product! I happened to install it over the weekend, and am a believer.

</comment><comment><USER26> Nice work guys! Congratulations.

</comment><comment><USER27> Congrats guys!</comment>


Ask HN: Ubuntu desktop virtualizion service? - <AUTHOR> I run 2 VMs: one to access sensitive accounts, and another to access risky/questionable sites.
Every month, I reset the images to their original snapshots to get rid of any vulnerabilities.
Is there a cloud service that will let me spawn new desktops that I can remotely connect to, instead of having to run VMs on my own machine? <comment><USER2> You can do it yourself with AWS, Azure, etc. There are many ways to set it up, see

[https://www.bing.com/search?q=ubuntu+remote+desktop+aws](https://www.bing.com/search?q=ubuntu+remote+desktop+aws)

It is affordable so long as (1) you turn the machine off when you are not using it, and (2) you don't allocate a huge amount of storage. It is easy to attach a 500GB volume but you pay for that even when the server is shut down; the cost for 10GB of storage is almost nothing in comparison.

<comment><AUTHOR> Hey thanks, I tried searching but couldn't put the right words together. This is helpful.

</comment></comment><comment><USER3> [https://www.paperspace.com/](https://www.paperspace.com/)</comment>


Education hackathon is giving away a school bus - <AUTHOR> http://blog.dwolla.com/hack-to-school/

<comment><USER2> Wow, a schoolbus! I've been wanting to get one for years, just gotta get first place now!

Seriously though, I like the idea of bringing these different types of people together (students, developers, teachers). Too often people think they know how to "fix education" without seeing the perspectives of everyone involved.</comment>


The hack that saved the astronauts of the Apollo XIII - <AUTHOR> http://sploid.gizmodo.com/this-is-the-actual-hack-that-saved-the-astronauts-of-th-1598385593 <comment><USER2> _> 'It seems amazing to me that he looks so calm and cool when they were actually being poisoned by their own CO2 and without knowing if they were going to make it alive to Earth.'_

Though our problems aren't close to same order of magnitude - keeping calm under pressure is something I feel is rare and under-appreciated in technology.

More than once I've seen a person start shaking so bad they couldn't type or slot in a replacement module while working a serious outage.

Amusingly, I've also had a new manager flip-out and actually interfere with my triage efforts because I _' didn't look like I was taking the problem seriously'_ (read: calm).

I wonder what sort of techniques could be adapted from elsewhere to teach the tech engineers of the world how to hold it together?

<comment><USER3> Nearly every place I've worked I've had two divergent messages come my way. The first is usually that I'm really productive, positive member of the team, and this shows up in reviews, promotions, etc. The other is that I just don't look like I give a shit about anything we're doing. The truth is that I honestly don't get emotionally invested in any of it. I'm emotionally invested in my career and love new technology, enjoy learning, etc. But if the proverbial shit hits the fan then it's a minor nuisance because I'll probably be working late for the night or for the next few weeks depending on how big of a problem has arisen.

<comment><USER2> I can relate.

 _> 'The truth is that I honestly don't get emotionally invested in any of it. I'm emotionally invested in my career and love new technology, enjoy learning, etc.'_

I think there's a lot of wisdom in those sentences. Basically, invest in internal (personal) goals and see the external (workplace) ones served as a natural extension of that.

It's easy to reverse that and find yourself hamstrung or run ragged by bullshit which you don't necessarily have any control over.

</comment></comment></comment><comment><USER4> The hack is awesome, but to me the real lesson is the importance of modularity. If North American Aviation and Grumman had standardized on the same part the hack would have been moot. Just take the part from the LEM and stick it in the CSM. End of story.

I fully comprehend the tradeoff here though, particularly when it comes to tight deadlines and weight tolerances. The CO2 scrubber in the CSM didn't need to be as beefy as the one in the LEM, and the two air filtration systems were designed by different companies where coordination would have been a bitch.

It's the classic software engineering trade off, isn't it? Add more dependencies or DIY. I wonder how the ISS deals with this in the US vs Russian parts of the station?

<comment><USER5> I have worked a bit on things related to the ISS. From what I learnt, it is basically two space stations stuck together with an adapter. The smaller Russian part was launched first and is self-contained, basically a MIR 2. The US/international part was then added piece by piece, with each part having a specialized function.

Visiting Russian spacecraft can only dock on the Russian side and the Space Shuttle only on the US side, unless it brought an adapter.

I'm sure there were still many compatibility issues. For example the European ATV docks on the Russian side.

<comment><USER4> This made me curious and I found this page on wikipedia: [http://en.wikipedia.org/wiki/Spacecraft_Docking_and_Berthing...](http://en.wikipedia.org/wiki/Spacecraft_Docking_and_Berthing_Mechanisms#Adapters)

Totally fascinating subject. It wasn't clear to me if Dragon 2 is going to use the APAS-95 connector (what the Shuttle used), or the newer NDS connector.

It also made me think.. was there some kind of adapter used for Apollo missions after Apollo 13 for the CO2 scrubbers? Or was the hack the "official way" of getting around problem?

<comment><USER6> > Totally fascinating subject. It wasn't clear to me if Dragon 2 is going to > use the APAS-95 connector (what the Shuttle used), or the newer NDS > connector. Dragon 2 will use a newer connector, scheduled to go up on one of > the future Dragon missions, replacing the current APAS-95 connector. A bit > sad to see it go. :(

</comment></comment></comment></comment><comment><USER7> On my first day of engineering school we were given this problem and similar materials to work with.

Pretty much the best possible "real world" exercise that focuses on limited materials, time, and most importantly, simplicity of design and manufacture.

<comment><USER8> would like to know what were the results with lots of people trying out different approaches..

</comment></comment><comment><USER9> >This is the mother of all hacks, the genius device that saved the Apollo XIII crew from dying in their emergency return to Earth,

Not to detract from the accomplishment; but I'm confident that the astronauts would have been able to figure this out by themselves if needed, and didn't do so because of the command/control nature of NASA missions.

The instructions could have been shortened to: Fit the Command Module scrubber filter to the Lunar Module's filter hole. Use tape and plastic to seal the rig for proper airflow.

<comment><USER10> I also wonder if there were other issues on-board that required their attention or otherwise diverted on-board brainpower.

Not to mention they had a limited amount of equipment on-board, so they basically had ONE CHANCE to get it right; no room for trial-and-error. There was a surplus of equipment on the ground, so they had more of a chance to make mistakes and get it right before directing the crew on-board.

So yes, they would have been able to figure it out if needed, but I think there are other reasons besides NASA's (infamous) bureaucracy.

<comment><USER9> >so they basically had ONE CHANCE to get it right; no room for trial-and- error.

That isn't necessarily so, but it is definitely prudent to optimize the use of their limited supplies. To be fair, I agree it's better that they had more people looking at the problem, and I agree that it was the right thing way to do it; but it isn't as though astronauts are chimps, or even that mere mortals are always unable to improvise non-standard solutions.

</comment></comment></comment><comment><USER11> The creativity and ingenuity of small intelligent teams, with barely any resources, and extreme time constraints never ceases to amaze me.

<comment><USER12> It shows the value of giving very smart individuals a well-defined goal and uninterrupted time to work on it. It's a good case study in creative productivity.

<comment><USER13> Maybe a well-defined goal is an understatement

It is a extremely well defined goal, under strict constraints (but a lot of liberty otherwise - for example, using the flight plan cover) and under a lot of pressure.

You can have immense bursts of productivity this way, but it also wears you out a lot.

</comment></comment></comment><comment><USER14> That scene in the movie ("you have to make this, fit into this, using these") was a big aha moment for me, in realizing just how fundamentally hard space travel really was. I'm very glad to learn it wasn't movie-exaggerated.

</comment><comment><USER15> Pretty sure this thread from 2011 is the source, has all the same text and images:

[http://www.therpf.com/showthread.php?t=105500&s=b4fc00db6d1b...](http://www.therpf.com/showthread.php?t=105500&s=b4fc00db6d1b757d8c879f3fe0555fc5&p=1516704&viewfull=1#post1516704)

I skimmed the thread and it looks like at least two people made their own replicas. The most surprising thing to me is that you can get used Apollo lithium-hydroxide canisters just like those pictured on ebay!

</comment><comment><USER16> If they sealed the bag around the canister with duct tape, couldn't they just tape one of the 3 bags if it ripped?

<comment><AUTHOR> Possibly, but I assume the astronauts would have been the judge of that if it did happen. Remember they were also very constrained on how much duct tape they had, so using a spare may have been more efficient than using more tape.

<comment><USER17> Ah! That explains the small strips of duct tape—tear it lengthwise to double your available tape.

<comment><AUTHOR> Exactly. Even if they had a hundred rolls, it would still have been good practice to be frugal with it. They run into similar things on the ISS: everything is limited except for vacuum. Being efficient and careful with resources is extremely important in those environments;

</comment></comment></comment></comment><comment><USER18> This is a good reminder to re-read _Lost Moon_ , Jim Lovell's account of the mission.

</comment><comment><USER19> Are there public records of who came up with the hack?

<comment><USER20> I don't know about public records, but if you believe this Reddit AMA, it was an MIT grad student. [http://www.reddit.com/r/IAmA/comments/xove1/iama_97_year_old...](http://www.reddit.com/r/IAmA/comments/xove1/iama_97_year_old_that_worked_apollo_missions_1/c5oaobm)

</comment></comment><comment><USER21> This took McGuivering to a whole new level.

</comment><comment><USER22> [x] duct tape

McGyver didn't lie.</comment>


Google founders' private air terminal in California - <AUTHOR> http://ontechies.com/2014/01/17/google-founders-private-air-terminal-in-california/

<comment><USER2> Pretty cool!

Worrying about where you're going to keep your planes for a year - what a problem to have! I get pretty concerned about my cats if I go on holiday.</comment>


A gentle introduction to statistical relational learning - <AUTHOR> http://phdp.github.io/posts/2015-07-13-srl-code.html

<comment><USER2> Can anyone explain to me how the "partition function" 'Z' is calculated? That part is a little glossed over in the post and the description in the paper is a little beyond my immediate understanding. :)

<comment><USER3> Partition functions are usually hard to compute as they require a sum or integral over the entire parameter space. In this case, it's "Z is a normalizing constant, that is: it's the sum of the values of all possible assignments."

So perhaps sum_x { exp( sum_i { w[i] * g[i](x) } ) }

</comment></comment><comment><USER4> reminds me of Progol :[http://www.doc.ic.ac.uk/~shm/progol.html](http://www.doc.ic.ac.uk/~shm/progol.html)

</comment><comment><USER5> FTA:

∀x:Add(x,0)=0

Whut? Shouldn't it be

∀x:Add(x,0)=x ?

<comment><USER6> Ugh! That was silly... It's fixed now, thanks!</comment></comment>


Redux-query – A React/Redux library for querying and managing network state - <AUTHOR> https://amplitude.engineering/introducing-redux-query-7734e7215b3b <comment><USER2> If anyone's interested, I maintain a list of Redux-related addons and utilities over at [https://github.com/markerikson/redux-ecosystem- links](https://github.com/markerikson/redux-ecosystem-links) . Includes just about every vaguely-useful-looking middleware, action-generation utility, devtool, store enhancer, fill-in-category-here, that I've seen out there.

(And yes, I already had redux-query in the list before this post :) )

<comment><AUTHOR> Awesome resource! And thanks!

<comment><USER2> Sure. I'll also throw in a pointer to my React/Redux links list, which contains links to high-quality tutorials, articles, and other resources for React, Redux, ES6, Webpack , and related topics. Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a source of solid info on more advanced topics:

[https://github.com/markerikson/react-redux- links](https://github.com/markerikson/react-redux-links)

</comment></comment></comment><comment><USER3> I love react, with the reusable components and the ergonomic of jsx but I really don't like what redux does to your code: it involves too much magic, you lose the concept of independent components and every change becomes a global one: everybody is notified of the inner state of each component …

To me it just break all encapsulation and just lead to massive tangled code that is really hard to maintain …

Edit: I want to clarify what I mean with the «too much magic» part. It's not redux itself which has too much magic in it, just your application flow that becomes magic when using redux, especially with libraries like the one showed by this article or redux-form[1].

[1]: [http://redux-form.com/](http://redux-form.com/)

<comment><USER4> The beauty of redux itself is the lack of magic. It's essentially just a design pattern and is trivial to follow.

So the "edit" part of your comment is key here: frameworks built on top of redux, including middlewares, store enhancers and stuff can definitely lead to an app that is hard to reason about with side effects happening in places you don't expect.

IMO that ends up being the worse of both world: even with all that tooling, Redux is far from terse (in favor of being explicit), but you also get the drawback of a deeply layered framework. This isn't worth it. There are other frameworks and tools that do this better. If you want to be terse, and don't mind throwing in a lot of layers on top of your code to achieve it, use one of the countless other (mainstream!) solutions to do so.

Redux really excel at "putting the code in your face", giving you easy to follow logic where very little is abstracted (and when it's abstracted, it's just via simple function composition). And at doing that, it is amazing and is my pattern of choice. At anything that diverge from that though, it is so bad it's not funny. Right tool for the right job :)

<comment><USER5> Redux is difficult to reason about because side-effects can be triggered from anywhere in the application by middleware.

If you're using something like redux-thunk, a single dispatch can cause both a store mutation AND trigger a side effect, which is confusing. I'd rather have those be 2 separate concerns.

Those dispatches can be triggered from anywhere in the app, and multiple middlewares may trigger multiple side-effects in new and exciting ways.

I find that logic to be difficult to follow and test.

I wish it had a more opinionated way to do side-effects, but the solutions like redux-saga seem even more complicated and confusing.

<comment><USER4> yup. Its like i said: redux is simple. Middlewares are what makes it complicated.

Redux-loop had a nice model for side effects, but the syntax did not mesh well with javascript limitations. Redux-saga is nice for testing, but it adds new non-standard concepts on top of generators that make it complicated. I really like the Netflix solution (redux-observable).

Since JS is not Haskell, side effects can be shoved to the side a bit, but there aren't a whole lot of ways to make them nice.

CycleJS probably has one of the better systems. In Redux, even without redux- observables, if you closely follow redux semantics I find that reasoning around thunks works quite well (if you're making sure that your actions are semantic and not glorified setters)

<comment><USER6> +1 for redux-observables, I've found RxJS to be an excellent tool for managing async without going insane.

I'd also second the notion to be rigorously consistent in following the semantics. I always end up regretting shortcuts.

</comment></comment></comment></comment></comment><comment><USER7> This is really cool! We have been using react-refetch from Heroku [1] for a similar purpose and it will be nice to have all our state in Redux. Another perk is that LogRocket [2] will capture this data now :)

[1] [https://github.com/heroku/react-refetch](https://github.com/heroku/react- refetch) [2] [https://logrocket.com/](https://logrocket.com/)

</comment><comment><USER8> Heh, I made the same thing but with global endpoints and swappable drivers so that components can be shared and endpoints can be stubbed/mocked: [https://gitHub.com/tonyhb/tectonic](https://gitHub.com/tonyhb/tectonic)

Think that genraally we're learning that these things should be automated for us: loading data traditionally sucks. GraphQL is really where it's at!

edit: that mobile keyboard though...

<comment><USER9> Yeah, Apollo Client helps you do a lot of these kinds of things with GraphQL - deduplicating requests, keeping track of loading states, etc: dev.apollodata.com (disclaimer: I work on Apollo)

</comment></comment><comment><USER10> I've been having this discussion both in my own head and with my team for the last couple of weeks and have been thinking about how to implement something like this (but haven't got around to it). Looks great!

</comment><comment><USER5> I've been experimenting with using a component to fetch data. The data to fetch is declaratively described as props.

[https://github.com/limscoder/react- wrangler](https://github.com/limscoder/react-wrangler)

It uses immutable and allows for time travel debugging.

<comment><USER11> That's a really neat approach. I like how it allows you to trigger code on missing paths. That seems like a really simple way to model an API.

</comment></comment><comment><USER12> This is cool, I was looking a library which would help me with CRUD and paging data recently and there weren't a lot of great options. So I started working on a library which ended up looking kind of similar to this.

One of the goals I've had is to stay encapsulated and not force any decision on the developer for the request library like redux-query does. I also try to avoid touching their data.

It isn't quite flushed out all the way, and needs more test, but I've started using it and enjoyed the way it works.

I'd love any feedback if anyone wanted to check it out, [https://github.com/SpinGo/crudux](https://github.com/SpinGo/crudux)

</comment><comment><USER11> This looks like a really great library for simplifying API interactions.

I'm curious though if there's any way to indicate that a component depends on more than one end point. Would you just wrap it in multiple `connectRequest` wrappers?

<comment><AUTHOR> Author here. Thanks!

That's what we do. It's an OK workaround but ideally `connectRequest` would support multiple queries. Another workaround is to manually dispatch `requestAsync` actions, which might be necessary if you need to chain the requests.

<comment><USER13> We were just about to start migrating to GraphQL and Apollo, so this definitely came out at the right time.

Our issue is that our API is nested, and does require many nested requests. This would probably be the best solution for us though.

Unfortunately, I don't see anything related to server-side rendering?

<comment><AUTHOR> Yeah server-side rendering hasn't been a focus for us. Currently, I don't think it is a great solution for server-side-rendered apps. I'm not exactly sure how much it would take to improve things here.

If you have any thoughts around multiple requests or server-side rendering feel free to submit an issue on Github to discuss! [https://github.com/amplitude/redux- query/issues](https://github.com/amplitude/redux-query/issues)

</comment></comment></comment></comment><comment><USER14> I'm very surprised that Relay is not getting more traction in this space. Given, it's a lot of work to get it set up and running but once it's in place it's great. I haven't found a library that manages network state and the associated difficulties that come with it better.

No reason why you cannot combine both Redux + Relay, in fact once the app gets to a certain size and you want to rely less on passing around long chains of callbacks and state objects then you pretty much have to implement either Redux, Mobx or similar.

<comment><USER9> We built a new GraphQL client that makes it especially easy to integrate with Redux, which also handles all of the related concerns about data caching and state management: [http://dev.apollodata.com/](http://dev.apollodata.com/)

</comment></comment><comment><USER15> Everyone says redux and react make for great component isolation.

How many of you people who use this combo can swap redux out at a whim, for another state management tool? How many of your components have been modified to work with the opinions of redux? Why do i need to couple my components with redux using connect()?

In my experience, redux and react on there own present decent patterns to simplify UI experience, but ive never seen a discussion that involves them that doesnt couple one with the other.

<comment><USER16> Swapping the management would be difficult, they all have their own patterns and implementations. But swapping Redux is absolutely possible. The logic sits in a self contained container which you can plug into literally every framework under the sun. The "connect" you're talking about is in place for React, Ember, Angular, Vue, Knockout, Mithril, Cycle, etc. Redux is also the closest you can get to a true universal app, because you can share it between code-bases (desktop app, web app, mobile app, backend even if you need).

We deploy a library based on this. It has reactive/changing datastructures that need to be presented visually. It runs on redux internally, and that is what makes it possible for our customers to embed it, no matter which framework they choose, even if it's JQuery. They form a simple dress and get served the properties and actions to display and excute. "Connect" makes their stuff aware of changes.

</comment></comment><comment><USER17> Nice component, we are working internally on something same, but for Kotlin.Js + React (nothing to show yet), but i have one question:

How to solve a problem when same entities have different fields, for example: List of members of a chat should display avatar, name and username, but viewing profile usually use much much more data to display. How to merge them? How to keep fields in sync and not to download everything in all requests. For example, loading all members can be slow when fetching full user profiles and should be avoided.

</comment><comment><USER18> I don't understand how this solution differs from actual side-effects managing libraries such as redux-saga or redux-cycles. Network requests are certainly side-effects and putting all their logic together with your Container code seems like a code-smell.

</comment><comment><USER19> I managed network state using react in the DOM itself, using hidden divs with custom onDidMount, onWillUnmount hooks. Worked really well.</comment>


ChaiScript - Easy to use scripting for C++ - <AUTHOR> http://www.chaiscript.com/ <comment><USER2> It'd be great if there were some good examples of the script up there on the front page - even after a few minutes of clicking around - I had only seen C++, no ChaiScript.

This did not really give me any feel for whether I would want it embedded in my project or not.

<comment><USER3> I gave up before I even found any ChaiScript code. Ok, so I see its easy to embed, but whats the language like!?

Didn't do much to convince me. I'll stick with Javascript (QtScript really; which is insanely easy to integrate into a C++ Qt project) and Lua (with the excellent LuaJIT) for my embeddable language needs.

</comment></comment><comment><USER4> I hadn't been aware of ChaiScript until now, but its C++ binding techniques are similar to what I developed for my LikeMagic project, a (mostly-)language- independent C++ script language binding project, with Io as its first backend language. Interesting case of parallel evolution; I'll have to contact the author to see if he wants to collaborate on ideas - we even happen to use the same BSD license for our two projects.

<https://github.com/dennisferron/LikeMagic>

</comment><comment><USER5> Saying this is the "only" EMSCAscript compatible c++ scripting language seems a rather debatable claim

See: <http://en.wikipedia.org/wiki/QtScript>

Obviously, Qt script is designed for c++ plus Qt whereas this is designed for c++ plus Boost. I personally think Boost is over-complicated ridiculousness but maybe that's just me. Still, there is at least one alternative to Chaiscript, if not more.

<comment> alok-g It says it's "ECMAScript-inspired". "Only" is used for "designed from the ground up with C++ compatibility".

</comment></comment><comment><USER6> IMO, it would really help if the main page quickly discussed the differences and similarities between chaiscript, python, and C++. I couldn't find that explanation, but I only surfed the page for 30 seconds or so.

Looks cool.

<comment><USER7> Also imho comparison between standard ECMAscript and Chaiscript would be welcome.

</comment></comment><comment> alok-g See also: <http://softintegration.com/>

</comment><comment><USER8> Interesting middle ground between Swig+(C++)+$scripting_language and pure C++.

A key weakness I see here is the lack of a standard library for Chaiscript.

If I choose to use my preferred approach of Swig+(C++)+Tcl, I get a command line REPL shell and Tcl's excellent file I/O stuff, regex, string functions etc for free (the Tcl pieces I mentioned are never the efficiency bottlenecks in the sort of compute-intensive programs I write).

I don't see enough here to convince me that it's better than pure C++ or swig+scripting language.</comment>


Australian uses snack bags as Faraday cage to block tracking by employer - <AUTHOR> https://arstechnica.com/information-technology/2017/11/australian-man-uses-snack-bags-as-faraday-cage-to-block-tracking-by-employer/ <comment><USER2> > Colella is now apparently living the flexible work schedule life in full—NPR > reports he is now working as an Uber driver.

and being GPS tracked more intensively than ever before. oh, sweet irony :D

<comment><USER3> When I used to work as a security guard, I used to cheat my security rounds. Who wanted to make a round every hour or 30 mins.

Things changed like 8 years ago, now every security guard needs to scan a bar code at various places to show that he/she is indeed doing his/her rounds.

<comment><USER4> Couldn't you just snap a photo of the barcodes, then scan a printout next time?

<comment><USER5> Couldn't he just ... do anything else except shirk?

<comment><USER4> Certainly, but I'm actually questioning the efficacy of the barcode system in preventing shirking, not this individual's questionable choices.

</comment></comment></comment></comment></comment><comment><USER6> The key here being that he _openly stored his PDA device in an empty foil "Twisties" bag_.

Openly. Made no secret of his subterfuge. Maybe even boasted about it what a dope.

<comment><USER7> There's no point making it a secret, once someone looks at the GPS logs his would have gaping holes in the logs compared to other workmates. You can hide where you are, but you can't hide that you are hiding.

<comment><USER8> Well you can fake GPS coordinates but it's typically much more difficult.

<comment> yjftsjthsd-h Doesn't Android at least have a debugging option to fake location?

</comment></comment></comment></comment><comment><USER9> What I don't get: why would you prefer the greasy inside of a snack bag for the PDA over a clean piece of aluminum wrap? Surely, he will have to use the device after he's done golfing.

And why didn't he just leave the device on some bogus location outside the golf court so the tracking wouldn't be interrupted? Surely, when asked where he was all day, he would have to be able to name some location, so it would be better to actually leave the phone there.

<comment><USER10> If you don't want to get the phone greasy, turn the bag inside-out.

If you don't want to get everything else greasy, put the inverted bag inside another bag.

Bonus: Two layers of shielding.

<comment><USER11> +1 :)

<comment><USER11> 4 downvotes for "like"ing the 2-bag technique ? I am amazed. In a puzzle i was asked long ago, the solution was similar to this.

<comment><USER12> General rule on HN: if your comment doesn't contribute usefully to the discussion, _don 't comment_!

</comment></comment></comment></comment></comment><comment><USER13> The man didn't want to be tracked, so he went to work for Uber.

<comment><USER14> I definitely understand not wanting to be tracked.

In this case, though, it looks like he mostly did it he so he could say he was working (and get paid) while he was actually out playing golf.

At least as an Uber driver, he can play golf as much as he'd like! Although he'll now have to choose been playing golf and making money.

<comment><USER15> He _gets_ to choose.

That flexibility is very valuable itself.

<comment><USER16> He didn't want to be a clockwork orange.

He preserved his own ability to choose, but then when he chose, he chose poorly.

YPTFPSD: Read the book by Anthony Burgess. The exposition character explains the ethics of choice in the context of mechanical fruits.

The main thrust of the book is that if you remove the human capacity to choose to do wrong, you also strip the choice to do right of all its virtue. You have to let Alex and his droogs be thugs, or we would all become robots. We'd all be clockwork oranges on a mechanical orange tree, clicking and whirring away with only our pre-programmed gears to guide us.

<comment><USER17> > YPTFPSD

I'll bite, please, can you tell me what that means? Googling brings this post up as the only useful result.

<comment><USER16> You're Posting Too Fast. Please Slow Down.

It's what HN tells you whenever you try to write more than about five posts every four hours. I don't know the actual parameters, but they are ridiculously conservative, and very obviously waived for certain accounts.

When it happens, the only way to actually provide a meaningful response to someone in a timely fashion is to edit a previous post. Which breaks the expected flow of a conversation, obviously. It's the thing I hate most about HN, without reservation.

<comment><USER18> You can also "provide a meaningful response in a timely fashion" if any of the recent messages get upvoted. It can be a little annoying but the easy solution is to consider how useful your comment is to the community before hitting submit.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> Yeah, the guy was clever but clearly cheating and he deserves to be fired. Now, about that reporter:

> Aluminum is not a great conductor—it heats up when a lot of power is pushed > through it—so a snack bag would potentially melt if it was used to try to > block a strong radio signal from inside.

Uh... what? I mean, I guess, if you're operating a tracking radar or long distance microwave transmitter inside that snack bag, sure. But a LTE radio with a GPS? Are you serious?

<comment><USER20> Aren't power lines aluminium?

<comment><USER21> Indeed, they often consist of aluminium for conductivity and steel for stability.

</comment></comment></comment><comment><USER22> Same trick as in the Will Smith film Enemy of the State (except Smith is trying to block government tracking)

<comment><USER23> That movie was spot-on about so many privacy and surveillance issues we have today (almost 20 years ago...). However Faraday cages were already a pretty known trick, this guy "just" innovated with the material used.

<comment><USER24> Parent comment is about the fact that snack bag is already used as a Faraday cage in that movie, so your last line is wrong

<comment><USER23> I've watched it 20 years ago so I don't remember seeing such scene. I do remember Gene Hackman explaining about cages when his hideout is shown though.

<comment><USER25> It's in the scene in the hotel lift - Hackman gets Smith to remove various things, and stuffs the trackers in a foil crisp (aka chip) packet, and the techs lose tracking on them.

<comment><USER26> [https://youtu.be/2u6KdHmoMbw?t=35s](https://youtu.be/2u6KdHmoMbw?t=35s)

</comment></comment></comment></comment></comment></comment><comment><USER27> We are really going full-steam to innate slavery in a trust-less society, everybody's movement optimized for maximal profit, and enforced by crab mentality "why should anyone have fun?"... Is there some sane place left?

The business owners would never subject themselves to this...

<comment><USER28> Now he is working for himself and can things at his own pace.

<comment><USER29> He is, but the rest of his former co-workers aren't, nor his replacement.

<comment><USER28> When they are ready, they too can join him on Uber.

</comment></comment></comment></comment><comment><USER30> We've also got tracking clauses in our employment stuff (specifically the work phone).

Not ideal, but frankly I'm not particularly worried. I can leave the phone at home & frankly employer isn't a privacy concern for me.

Big data companies that can make connections between data sets & crunch it for patterns etc...that I'm less keen on.

<comment><USER31> Personally, I would not agree to being tracked by an employer, unless there was a really good reason, e.g. safety concerns, as it invites abuse of power, even unintentionally.

Stuff like this exacerbates disrespect, distrust and suspicion in employer/employee relationships, in a way I believe no one benefits. Employers tend to use these tools to aggressively police minor infractions, though pretending to only want to catch the few bad apples, driving away the good employees in favour of those who think they can game the system anyway with a tit-for-tat mindset.

In the end trust is eroded, everybody is unhappy, and the underlying issues as to why those bad apples aren't doing their jobs in the first place is never resolved or even investigated.

<comment><USER30> Philosophically I agree with your stance.

In practice - and particularly in my circumstances - I've found the tracking clause to be palatable, or at least begrudgingly acceptable.

Perhaps my employer is an outlier, but they don't enforce minor infractions at all. So while the manual says we can track you 24/7 the reality is there is no tracking - I literally get calls from my boss asking what country I'm in because half the time they don't know where I am or what I'm doing.

I've seen the actual policy employed twice - in both cases the employee did something deeply unethical. The top dogs take a very dim view on that kind of stuff so the employees found themselves on the wrong end of HR reviewing policy compliance carefully. So be it - I don't need sketchy co-workers.

</comment></comment></comment><comment><USER32> Impressive, I'm surprised chip bags can make effective faraday shields. I'd consider this grounds for promotion of this guy, he's obviously too clever for what he's doing.

</comment><comment><USER33> "Aluminum is not a great conductor" Compared to what? Graphene?

<comment><USER16> This threw me as well. Of the pure metals, the holy trinity for conductivity is silver, copper, and gold, with aluminum sliding in at 4th place. Due to cost considerations, copper and aluminum are the most widely used for conducting electricity, with aluminum about half as conductive as copper (therefore requiring different building code guidelines).

But I'm not sure that translates to aluminized-mylar. Sometimes conductors get weird in thin films or at material boundaries.

Organic compounds are great conductors whenever you can find a chain of delocalized p-orbitals, such as in graphene or cis-polyacetylene or polyaniline or polythiophene. PEDOT/PSS is a polymer related to polythiophene that is used in anti-static bags, transparent electrode, electrochromic films, capacitor cathodes, and it is printable. Polyaniline is typically used in batteries and supercaps.

So an aluminized-mylar chip bag is probably not a great conductor in comparison to one made from PEDOT/PSS backed with PET. And obviously, a chip bag made from graphene-on-copper-foil would be the best, if anyone could afford to buy a $1000 snack.

<comment><USER34> If you look at an aluminium mylar bag under a microscope you'll see that the coverage of aluminium is actually rather low, and it's more flakes of aluminium on the surface which don't connect with each other in places.

It's that lack of connection which makes it a lousy shield.

</comment></comment></comment><comment><USER35> Stupid question: why couldn't he just turn his phone off? If all signals are blocked, what's the difference on the other end?

<comment><USER36> Your phone logs when you turn it off and on. It can't log the difference in why you lost signal though. So this guy just says "See, my phone was on the whole time, but there was no signal at the work site..."

</comment></comment><comment><USER37> I had a great deal of sympathy for him preventing being tracked until I read that he did it so he could play golf instead of working.

</comment><comment><USER38> Not that I want crumbs on my phone, but how does one ground a snack bag with a phone in it?

<comment><USER39> There's no need for a Faraday cage to be grounded.

A car forms an acceptable Faraday cage to protect occupants when struck by lightning even when isolated by its rubber tires, and a plane can be struck by lightning thousands of feet from the ground and still protect its occupants (though the lightning will still damage electronics if they're in the current path through the machine).

<comment><USER40> Example with plane is better. For the voltages of lightning, car with rubber tires (possibly wet ones) is pretty much grounded.

Conductor and isolator are relative terms.

</comment></comment></comment><comment><USER41> looks like pants and jackets of the near future will feature Faraday cage pockets - switching the tracking on/off will be as easy as just moving smartphone from regular pocket into the Faraday one.

<comment><USER42> That's a brilliant product idea, I'd happily buy it off the shelf

<comment><USER43> There are pocket sized Faraday cage pouches, you could sew them into whatever pocket you want.

</comment></comment></comment><comment><USER44> Similar, I used to work for a guard company. We implemented a process where employees reported to work by calling from an assigned set of phones at each client. they also signed out of work by calling from the same number.

needless to say we had all sorts of attempts to use other numbers but that never would work. since we had ANI numbers I doubt they could be spoofed.

now we never went as far as having them call in hourly, likely that would be dependent on client requirements. still I understand why the guy in the article was fired and honestly if he was skipping out then so be it

<comment><USER45> > since we had ANI numbers I doubt they could be spoofed.

ANI is just the fancy name for what we call caller-id, it's not a special kind of phone number. It's also highly susceptible to spoofing...

<comment><USER46> Automatic Number Identification (ANI) is not the same system as caller ID. ANI is used for billing purposes and is harder to spoof than CID. Caller ID uses in-band tones which is why it's so easily spoofed.

</comment></comment></comment><comment><USER47> Article states that: "so a snack bag would potentially melt if it was used to try to block a strong radio signal from inside" \- but if remember correctly, unless grounded, Faraday's cage will not affect the inner source at all, right? Gauss's law is only about the sum of external sources being 0.

<comment><USER48> I would think that if it blocks outside signals from getting in, it would have to also block inside signals from getting out, because Maxwell's equations work equally well regardless of what direction time moves.

Imagine a charge inside a Faraday cage. You wiggle it around, causing electromagnetic waves. If those were not blocked, they would cause various charges outside the cage to wiggle around. Call this experiment #1.

That should mean that if instead of wiggling the inside charge around, you had wiggled all the outside charges around in the same pattern that experiment #1 caused them to wiggle in, the result should be the inside charge wiggling the same way you wiggled it in experiment #2.

</comment></comment><comment><USER49> Well, it's unfortunate that we have people like this who make employers feel the need to track their workers.

<comment><USER50> I'm not entirely convinced that "people like this" are the sole reason employers want, like, and do track every breath of employees.

<comment><USER51> > I'm not entirely convinced that "people like this" are the sole reason > employers want, like, and do track every breath of employees.

I would go further and assert that, in most cases, "people like this" probably aren't any, or are only a negligible part of the _reason_ , only the _excuse_ to allow them such tracking.

<comment><USER52> What is their actual purpose in tracking?

<comment><USER50> Honestly, I think it's mostly to assert their power over workers. It's natural for people to do this if they can: it feels good and makes them feel in control, even if it's not very effective or is downright detrimental to the bottom line. It's also natural to search for plausible excuses for such behavior - nobody wants to admit that they just get a boner (metaphorically) from bossing others around.

Just my general opinion, I have too little information to say if the tracking, in this case, is actually a rational and net-positive policy and not someone's power trip.

<comment><USER53> This is what I observed in all but 3 supervisors I've ever met (I had dozens), and that says a lot when coming from a guy with 17 years of career.

</comment></comment></comment></comment></comment></comment><comment><USER54> Note that unlike other metals aluminum only blocks some frequencies, not all frequencies. Low ones go through - magnets work quite effectively even through sheet aluminum and can transmit power. Which is what made Rossi's cold fusion "demonstrations" so suspicious to me.

</comment><comment><USER55> Note to self: keep a snack bag on myself at all times...just in cage...

</comment><comment><USER56> not even original! From the movie "Enemy of the State." This video at the 0:44 mark, Gene Hackman searches Will Smith and puts his stuff into an empty chip bag.

[https://www.youtube.com/watch?v=2u6KdHmoMbw](https://www.youtube.com/watch?v=2u6KdHmoMbw)</comment>


Copperhead, Guardian Project and F-Droid to Build Secure Mobile Ecosystem - e-sushi http://blog.e-sushi.net/post/142166015174/copperhead-guardian-project-f-droid-to-build <comment><AUTHOR> "Please disable your ad blocker… thanks!"</comment>


Apple uses Amazon AWS when receiving attachments from the new Messages app - <AUTHOR> http://imgur.com/fwXX5 <comment><USER2> Apple already uses AWS and Azure for iCloud, so this makes sense. "Apple has selected Microsoft's Azure and Amazon's AWS to jointly host its iCloud service" [http://www.theregister.co.uk/2011/09/02/icloud_runs_on_micro...](http://www.theregister.co.uk/2011/09/02/icloud_runs_on_microsoft_azure_and_amazon/)</comment>


So That's Why Hulu Hates Boxee - <AUTHOR> http://gigaom.com/2009/05/28/so-thats-why-hulu-hates-boxee/ <comment><USER2> "'Right now we're committed to Hulu being an online experience, and that's where our vision is today, and I think that will continue.' Right! That is why Hulu released the desktop version."

So desktop apps can't be connected to the Internet?

He even says why they went after Boxee in his article, but doesn't realize it: ". . .can only be used on PCs. Of course, we wouldn't expect the company to do it any other way — after all, if it ran on set-top boxes, it would dry up the lucrative money stream that flows from cable operators to Hulu's partners and parents."

Boxee allowed Hulu to be viewed on TVs. Hulu doesn't care that you watched their ads _on your computer through Boxee_ , they cared that people were using Boxee to put it on their TVs.

<comment><USER3> Good point. People forget that Hulu are not a scrappy startup. They are wholly-owned by big media.</comment></comment>


Processing in JS is beautiful - <AUTHOR> http://processingjs.org/

<comment><USER2> The Processing.JS port is amazing in and of itself, but also check out the portfolio of the guy who designed the site, Alistair MacDonald. You can see an index of his Processing experiments here:<http://www.hyper- metrix.com/#Processing>. You can also follow him on Twitter @F1LT3R. Very interesting work.

</comment><comment><USER3> I remember reading about the JS port of Processing last year. It's amazing to see what can be accomplished with the HTML5 canvas. Hopefully, the adoption of HTML5 is faster than most other standards, otherwise, it's almost easier to download a plugin.</comment>


Uber cheats their customers and pockets $15/mo AMEX credits - <AUTHOR> https://thepointsguy.com/news/amex-credit-uber-cash/ <comment><AUTHOR> How it worked before:

AMEX Platinum comes with $15/mo Uber credit. Credit auto-expires by the end of each month.

Before - this credit automatically applied to ride and the rest charged to default credit card.

Now Uber got clever and decided to pull the fast one on their customers (and AMEX). $15 AMEX credit now pushed to "Uber cash".

And you can only apply this credit to rides that are <$15.

If ride is more expensive - you cannot apply Uber Cash credit unless you refill "Uber cash".

But here's another trick - you can only refill Uber Cash with $25, $50 and $100 chunks.

Which means if you got AMEX credit of $15 but your ride is $50 - in order to use the "uber cash" balance you can only refill your Uber cash with another $50 which doesn't make any sense for customer. You'll always be keeping leftover balance on "Uber cash". Without lending UBER your own money through "Uber cash" refills - your AMEX credits will auto-expire at the end of every month.

This way your $15 AMEX credit is expires unused by the end of every month effectively cheating customer away from reward and diminishing AMEX-promised reward program.

FRAUD!

</comment><comment><USER2> I'm not vision-impaired and have a really hard time reading this wispy-thin font on a white background.

Designers who read this: please consider usability of people who don't have perfect vision.</comment>


Microsoft Open-Sources GW-Basic - <AUTHOR> https://devblogs.microsoft.com/commandline/microsoft-open-sources-gw-basic/ <comment><USER2> Another thread: [https://news.ycombinator.com/item?id=23266917](https://news.ycombinator.com/item?id=23266917)

</comment><comment><USER3> I love how the last git commit is dated "Feb 11, 1983"

<comment><USER4> Interesting. Didnt Linus Torvalds create GIT around 2005??

<comment><USER5> You can arbitrarily amend the date in git

      git commit --amend --date="Thu Jan 1 08:00 1970 +0000"</comment></comment></comment>


1password explain the new Dropbox terms - <AUTHOR> http://blog.agilebits.com/2011/07/dropbox-terms/ <comment><USER2> The DropBox hoopla shows the downside of writing your terms in a readable language: people actually read them out of curiosity.

And since people have no clue how to interpret the legal bits that are necessarily included if you don't want to be sued into oblivion, they completely misunderstand them.

So the lesson is: keep your T&Cs cryptic, unintelligible, long, boring, etc - so that people don't read them. This way you can put whatever you want in them, including potentially nasty clauses (unlike the clause we're discussing here), since no one will read it anyway.

<comment><USER3> I can't tell if your opinion is lathered with sarcasm or brutal honesty.

BagCheck has a nicely done Terms page which annotates legalese with Plain English - <http://bagcheck.com/terms>

It is odd (and somewhat heartening) to learn that so many people _still_ read those paragraphs of text nobody is supposedly reading.

</comment></comment><comment><USER4> Here's my complaint. The author is complaining about a big furor over the TOCs, and then proceeds to show us the TOCs that "seems" to be behind it.

Here are the facts:

      * Dropbox released new TOCs.
      * There was a big furor.
      * Dropbox *modified* the TOCs.
      * Furor ended.

Regardless of whether or not, in your opinion, the TOCs were significantly modified, the fact is that:

      * The author presents the modified version of the TOCs.
      * The author claims that the modified version caused the furor.

This is patently false.

</comment><comment><USER5> Does Dropbox keep a revision history of your 1password data? It does that by default with other files.

If there is a Dropbox breach, I would want to prevent hackers from getting their hands on older versions of my passwords locked with an outdated (eg, no longer top secret) master password.

</comment><comment><USER6> WebDAV is too slow? Really? Wow, I guess all those sharepoint users around the world must be cursing Webdav, along with the MobileMe users (and soon to be iCloud users, no doubt).

Also claims that APIs aren't available for other platforms, I find a little disingenuous. Wuala supports iPhone, Android as well as Win, Mac and Linux. I would struggle to understand how Wuala wouldn't want to provide 1Password with access to an already existing API on the aforementioned mobile platforms.

<comment><USER7> I curse Sharepoint with every time I have to use it (and its WebDAV implementation only works _well_ with Windows). If you haven't noticed, iDisk is one of those things that doesn't work well with MobileMe.

1Password also uses a _lot_ of _tiny_ files in its workflow (one of my items, a license stored in 1Password, ffdfa… has a 5k PNG, a 261 byte plist, and a 791 byte JSON file in two different directories; those separate files and directories are what make the sync efficient). Share point deals with larger files over WebDAV, where it can be more efficient for those files.

If you spent five minutes on the Wuala website you would notice that they _only_ have a GET series of APIs, not anything that the 1Password guys can use because the mobile apps can _write_ as well as read. So, no, they aren't wrong.

</comment></comment><comment><USER4> Except that the excerpt you posted is the new, modified version after all the furor.

[http://hardware.slashdot.org/story/11/07/02/0515218/Dropbox-...](http://hardware.slashdot.org/story/11/07/02/0515218/Dropbox- TOS-Includes-Broad-Copyright-License)

Compare the above version to this new form: "This license is solely to enable us to technically administer, display, and operate the Services"

It would appear that you didn't look into the issue at all before jumping to the defense of your main service provider. Is this the level of diligence we can expect from your product?

But, hey, welcome to the party.

</comment><comment><USER4> Dont fucking mod me down. The author claims that this is the paragraph that caused the furor:

 _We sometimes need your permission to do what you ask us to do with your stuff (for example, hosting, making public, or sharing your files). By submitting your stuff to the Services, you grant us (and those we work with to provide the Services) worldwide, non-exclusive, royalty-free, sublicenseable rights to use, copy, distribute, prepare derivative works (such as translations or format conversions) of, perform, or publicly display that stuff to the extent reasonably necessary for the Service. This license is solely to enable us to technically administer, display, and operate the Services. You must ensure you have the rights you need to grant us that permission. [Emphasis added]_

When in fact this is the _modified_ version that was posted after the furor. The original version is this:

 _By submitting your stuff to the Services, you grant us (and those we work with to provide the Services) worldwide, non-exclusive, royalty-free, sublicenseable rights to use, copy, distribute, prepare derivative works (such as translations or format conversions) of, perform, or publicly display that stuff to the extent we think it necessary for the Service._

Significantly different. And it was changed for a reason.

<comment><USER8> _to the extent we think it necessary for the Service._

I know HN only has one viewpoint on these matters. However, I was hoping someone could explain to this poor soul how a scenario like the following is ruled out by this language:

I'm the dropbox CEO. I provide a free service for most of my users. As time goes on, I'm having trouble making ends meet. I find that unless I get more cash in the next 7 days, I will be unable to pay my hosting bill and my service will be shuttered. Thus, obtaining more cash is _necessary for the Service_.

Now along comes a firm, we'll just call them SLP. SLP is willing to give me a bridge loan on very good terms immediately. The only catch is that they require me to sublicense worldwide royalty-free rights to use, copy and publicly display all works stored in the dropbox service. Their purposes for wanting the data is unclear, however it is quite clear that I won't have oversight on the use of the data. I can imagine, however, that they might be interested in using it for data mining, advertising or industrial espionage. We don't speak of any details, though. If I revoke the license, the bridge loan plus penalties immediately comes due.

I can find no other source of funding at this time - I've played all my other cards. I, as the CEO, believe taking this loan at these terms is absolutely necessary if I am going to continue providing the service. So, I sign, sublicense, and don't actually inform even many people in my company let alone the user base. SLP quietly gets read only access to all the data. To whatever extent SLP uses this data, they believe their use of it is _necessary for the Service_ in that they don't believe the bridge loan will ever be repaid and they believe it is necessary to extract value from the data to recoup any losses they expect on the loan.

Now, mind you, I don't actually believe that dropbox has any sort of intent of doing something like this, or that they'd be likely to do so even if their back was against the wall. I also agree it's a pretty far fetched scenario.

I'm simply wondering how a license like this (and the multitide of others like it, I'm not intending to single dropbox out at all) prevents this behavior. You know, because I'm one of the total morons that can't understand simple english.

<comment><USER2> IANAL, but the "service" and the "company's survival" are not the same concept. When, as GrantTree, I sign an NDA to file a grant application for a client, it states, like most NDAs do, that I can disclose it to subcontractors/advisers/etc "for the performance of their work".

As a programmer, you might say, like you just have, "AHA! But if you don't pay your subcontractors, they won't do their work. So, for the performance of their work, you can sell your data to anyone, if the company's survival is threatened!"

Unfortunately (or fortunately), lawyers, judges, prosecutors and juries are not programmers, and I think you'll find they don't interpret it that way. "For the performance of their work" is clearly intended to mean "directly linked to their work" as well.

The same is true of the DropBox terms. "Necessary for the Service" does not mean "whatever you might imagine could be necessary if you were arguing with a magical genie as to the possible definitions of terms" - it means "what is directly necessary so that the service can operate as normal". So I don't think any judge or jury would accept that selling out all their customers was "necessary for the Service", in the hypothetical case you mention.

Remember, law isn't about theoretical logic - it's about practically resolving disputes between people.</comment></comment></comment>


18 hours, $33K, and 156,314 cores: Amazon cloud HPC hits a "petaflop" - <AUTHOR> http://arstechnica.com/information-technology/2013/11/18-hours-33k-and-156314-cores-amazon-cloud-hpc-hits-a-petaflop/

<comment><USER2> _" There are whole categories of problems that are pleasantly parallel, and in those cases the [Linpack maximum] number is really not as important because we did intentionally make use of the entire 1.2 petaflops because they were all concurrently executing the workloads," Stowe told Ars. "Maybe there does need to be a different metric for analytics and big data and genomics—and all these pleasantly parallel workloads that are becoming more pervasive."_

I wonder if people miss this part. For easily parallel projects, Amazon is great since any core can make progress regardless of the other cores state or reachability. But if there is any inter-dependence between the cores (I use the term engtangling but others have called it co-dependence) the number becomes limited by the bisection bandwidth between cores. Poorly scheduled (like randomly scheduling on a core) is the worst case, if you can keep the bandwidth between entangled cores high, even if the system bandwidth is low, you can improve things (dramatically some times). But at the end of the day its the level of sharing between cores that will tell you if you can do your problem in the 'cloud' or if you are going to need a local data center.

</comment><comment><USER3> Interesting to see that 'flops' has been redefined to 'flop' so that 'flops' now refers to the plural. Also interesting to see that arstechnica hijacks my back button.

Anyway, the real problem from what I've read in the literature is in problems that require network IO, but going back now, most of that seems to predate Amazon's HPC cloud service and even a year ago, some people have found pretty good scaling there: [http://www.computer.org/portal/web/computingnow/content?g=53...](http://www.computer.org/portal/web/computingnow/content?g=53319&type=article&urlTitle=massively- parallel-fluid-simulations-on-amazon-s-hpc-cloud).

</comment><comment><USER4> > including Amazon's cc2.8xlarge instance with 32 cores

they count AWS "vCores" which is 1 HT ( half-core).

</comment><comment><USER5> Theory is one thing, hands-on experimental scientific evidence another, not speaking about a possible route of synthesis and purification of polyaromatic cyclic hydrocarbons.

Does anyone know what problem/model was used for the calculations? I find it strange that there are many details about the hardware, but no information about the problem set in the field of organic solar cells.

<comment><USER6> Cycle is a HPC company that configures the software needed for these massively parallel computations, they don't actually do the protein modeling or any of the scientific research. That is all supplied from the customer. They basically setup the environment for the customer to massively "crunch the numbers."

</comment></comment><comment><USER7> What's the advantage of running 150k cores for 18 hours versus far fewer cores over a period of a few days or weeks? Is efficiency gained with increased concurrency while processing data in a certain way?

<comment><USER8> If you're going to spend the same amount either way, you might as well get the results back in a day.

</comment></comment><comment><USER9> See also: [https://news.ycombinator.com/item?id=6720969](https://news.ycombinator.com/item?id=6720969) for the Google cloud version.

</comment><comment><USER10> Very cool benchmark.</comment>