Portable Native Client - <AUTHOR> http://blog.chromium.org/2013/11/portable-native-client-pinnacle-of.html

<comment><USER2> [http://en.wikipedia.org/wiki/ActiveX](http://en.wikipedia.org/wiki/ActiveX) \- 1996 is knocking… yes, I know - it's very, very different this time, but still can't help remembering the horrors of ActiveX :)

PS. From Wikipedia article: _In principle it [ActiveX] is not dependent on Microsoft Windows, but in practice, most ActiveX controls require either Microsoft Windows or a Windows emulator_

PPS. I'm not really trying to compare them, just pointing out that obsessive idea to run Photoshop in browser is almost as old as browser and photoshop themselves. And so is the idea for a grand platform that will let us "write once, run everywhere". Uncountable attempts were made, yet somehow they all fall short of expectations. Is the idea itself flawed? Perhaps we have different operating systems for a reason?..

<comment><USER3> It seems like every time someone tries to replace javascript with a better solution someone has to bring up vendor lock-in. Are we supposed to just live with javascript for eternity? When javascript was introduced it only worked on netscape browsers than other browsers adopted it later. It wasn't made a spec until later.

<comment><USER4> Indeed. Every trial to replace "standards" is called "evil". From this perspective, the web platform is far from open. The result is we all are in a local optimum trap. I already gave up expecting cool future and decided to stick to the native development for a while (for a decade or more).

BTW, as a game developer, it would be nice if this rendering latency issue will be fixed soon.

\- [http://phoboslab.org/log/2012/06/measuring-input-lag-in- brow...](http://phoboslab.org/log/2012/06/measuring-input-lag-in-browsers)

\- [https://code.google.com/p/chromium/issues/detail?id=168459](https://code.google.com/p/chromium/issues/detail?id=168459)

I think this response time issue is a real show-stopper than JavaScript performance.

<comment><USER5> This along with the fact that you can't avoid GC when handling browser events makes it really hard to hit a consistent framerate for sure.

</comment></comment></comment></comment><comment><USER6> Ugh. Sounds like the next IE6 is here...

Can't wait to log into a bank that demands I installed Chrome to use their new 'security' or some web apps that won't run in anything but Chrome.

<comment><USER7> This seems like more of a ChromeOS move to me, so that you can run native code on Atom and X86 machines. The knock on ChromeOS is always that it's "just a browser". I seriously doubt anyone is going to write their Etsy storefront in NaCl. The benefit here, of course, is that if someone does write the next Photoshop for ChromeOS machines, it should also run fine in OS X, Windows and Linux. Seems like a win for portability to me.

<comment><USER8> That worked out well for Java.

<comment><USER9> No, but it did for Flash.

<comment><USER8> Let's just say I'm pretty happy I'm not maintaining any products built with Flex/Air.

</comment></comment></comment></comment></comment><comment><USER10> PNaCl has been in development for a while, I'm having trouble understanding just what is being announced here. Is PNaCl now enabled by default in Chrome?

I also hadn't seen pepper.js before, is that new?

<comment><USER11> > [http://codepen.io/lbebber/pen/xrwja](http://codepen.io/lbebber/pen/xrwja)

I think so. I just updated to Chrome 31 and it brought up a UAC in windows, which probably means that it was installing the PNaCl runtime since it usually doesn't require a UAC.

<comment><USER12> Or it could be Chrome asking to switch to installing in Program Files instead of User profile.

</comment></comment></comment><comment><USER13> Be interesting to see if this becomes a target for other languages, e.g. allowing browser applications to be written in Python.

<comment><USER14> What would be _really_ great to see is someone putting a HTML client/DOM implementation/etc. inside a PNaCL application. This is after all how things ought to be: ideally you implement your DSL/document viewer inside your general-purpose runtime, instead of kludging your document-format specification up into an application runtime. None of the big browser vendors (including Mozilla and Google itself) is going to welcome such an idea though, as it threatens their _de facto_ control over Web standards.

<comment><USER15> This is a similar idea to the MSR Embassies project: [http://research.microsoft.com/en- us/projects/embassies/](http://research.microsoft.com/en- us/projects/embassies/)

<comment><USER14> Looks like it. It's also similar to ideas which were (iirc) prevalent in the mid-to-late '90s about a modularised/componentised browser as the future of the Web.

</comment></comment></comment></comment><comment><USER16> Very good news! A lot of developers don't like JavaScript and HTML. Google started to listen. I really hope the rest of big players will follow the suite.

<comment><USER17> Be careful what you wish for because it might come true. A lot of people don't like the Open Web and are clamoring for something obfuscated. Longer term is lose-lose for everyone.

<comment><USER16> I don't understand how Web can be "Open" if your choice of language is limited to JS, HTML and CSS that are changing as quickly as standards committee is managing to react. And transpilers are just a second-class-citizen hack trying to make the best of situation.

<comment><USER18> Just write native applications and use normal network communications.

Plenty of choice available with 100% full hardware use.

</comment></comment></comment></comment><comment><USER19> The demos are cool, but are there any among them that can't be done in JS? I know I've seen Voronoi polys in JS that were way less janky than the one in the PNaCL demo.

<comment><USER14> Well, presumably you could implement a language with bignums in PNaCL with reasonable efficiency, something which is evidently not possible in JS.

<comment><USER20> Why is that evidently not possible? :) Serious question, I would guess anything that can be done in C - and bignums can - could be done well in JS, because typically C code compiled to JS runs at about half the speed of native.

If you have results showing otherwise for bignums, I would be very interested. Anything special about that particular problem?

<comment><USER14> > Why is that evidently not possible? :)

Because Mozilla assured us that it was not. Central to Mozilla's case against Dart was the assertion that parts of it - including bignums - could not be implemented efficiently by compiling to JS, leaving native Dart runtimes at a strong advantage.

<comment><USER20> Link?

<comment><USER14> Here we are: [https://news.ycombinator.com/item?id=3094072](https://news.ycombinator.com/item?id=3094072)

<comment><USER20> Thanks, reading that it says that native bignum support can speed things up. That's probably true - the only question is how much. If it's 25% vs 2,500% then that's what matters. I don't see an actual debate about numbers in that thread there, just generalities?

As I said above, I would expect JS to reach about half of the speed of C. It's possible that having native bignums would have removed some of that difference.

More importantly, the context here is PNaCl. Do you see a reason bignums could be emulated better in PNaCl vs JS? I assumed that's what you were implying, but perhaps I misunderstood you? Sorry if so.

<comment><USER19> I'm not sure the poster meant "bignum" as in huge numbers like GnuMP handles, or if he meant exact 64-bit integers, which JS doesn't have (natively).

<comment><USER20> I think true arbitrary-size bignums, because that's what Dart has?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> It says 'LLVM style intermediate code'; why not actual LLVM intermediate code? What would be the reason for an alternative? If it would be actual LLVM code it would be easier to compile from programming languages and to different backends, right?

<comment><USER22> It is based on LLVM, but presumably they have to modify it for their particular needs. The PNaCl bitcode reference manual goes into more detail: [https://developers.google.com/native- client/dev/reference/pn...](https://developers.google.com/native- client/dev/reference/pnacl-bitcode-abi)

<comment><USER23> More details on the design process are available here: [http://www.chromium.org/nativeclient/pnacl/stability-of- the-...](http://www.chromium.org/nativeclient/pnacl/stability-of-the-pnacl- bitcode-abi) (there's a link to a nicely formatted PDF in the bottom).

TL;DR: a lot of thought went into it :)

</comment></comment></comment><comment><USER5> For anyone who works on Chrome: does this mean that Chrome won't move to support asm.js? I tried searching the bug tracker and discussion group and couldn't find anything.

In general I'm really happy that we're getting faster (no-gc) runtimes, but I think I favor asm.js's approach due to its backwards compatibility (though I admit I am not aware of the nuances of each implementation).

<comment><USER24> Chrome has taken the approach of working on improving their V8 engine to (hopefully) achieve similar performance to Firefox's specialized asm.js AOT codepath but without any special handling of the "use asm" directive (which gives Firefox guarantees about variable types & stuff like that). See [https://news.ycombinator.com/item?id=6553794](https://news.ycombinator.com/item?id=6553794) for a discussion on the subject.

<comment><USER5> Great, thank you for the link!

</comment></comment></comment><comment><USER25> Why do people keep saying that PNaCL is like ActiveX, when it's nothing of the sort? Is this a failing on Google's PR?

<comment><USER26> Because lots of people are narrow minded apparently

</comment></comment><comment><USER27> Great news for zerovm too! Will this mean apps that run seamlessly on ARM and X86 boxes?

</comment><comment><USER28> Anyone know why it takes so long to load any of the demos on [http://gonativeclient.appspot.com/demo/bullet](http://gonativeclient.appspot.com/demo/bullet) ? They simply take way to long.

<comment><USER23> The PNaCl translator takes time to optimize the bitcode to highly-efficient machine code (which is almost on par with native performance). This only happens the first time you load the demo - afterwards the output is cached and the load should be instantaneous.

Translation time is one of the highest priorities of the PNaCl team and it should become significantly better in the future.

<comment><USER28> Sadly even after it loads and hitting refresh I still see a progress bar.

As google knows loading time really really matters and for such small demos it does not look good that it takes 10(?) seconds to load. Makes me wonder about larger applications.

<comment><USER23> Does it take the same amount of time to load on subsequent runs as on the initial run? This should not happen. Are you running in incognito mode, perhaps? (in that case, caching doesn't happen for obvious reasons). Feel free to submit a report on the native-client-discuss mailing list or through the bug tracker.

<comment><USER28> It is faster, say less than a half second and not the 10 seconds it was the first time, but still _very_ noticeable. Normal latest chrome on a Windows 2008 box.

</comment></comment></comment></comment></comment><comment><USER29> One thing I am concerned about is, since PNaCl is essentially yet another platform, how Google (or anyone) is going to manage the host of supporting tools required. Tools like dependency management, libraries, process control etc.

By the way, Google has already proven their "platform-creation" skills with Android.

</comment><comment><USER30> How is this different to Javascript? They both get jitted to native code (v8, llvm)...what's the benefit?

<comment><USER31> PNaCl bitcode is (mostly) statically-typed and has a C-like memory model, as opposed to dynamically-typed JavaScript. Dynamic typing has a run-time performance cost, and so does garbage collection.

<comment><USER32> Are you sure that PNaCl bitcode is typed at all?

<comment><USER31> It's kind-of typed. They kept the basic integer and floating-point types from LLVM (i8, i32, i64, double) and pointers, but removed structures and arrays. It's "more typed" than JavaScript, but less than C++. This still means that numeric code (working with integers and floats) is going to be at least an order of magnitude faster than on JS.

</comment></comment></comment></comment><comment><USER33> I am actually looking at saying good bye to browser (html / css / js and all the madness) and hello to apps that connect to dropbox or s3 or some such cheep server.

</comment><comment><USER34> Isn't it better to ship uncompiled C++ code directly, instead of decompiling and recompiling already compiled code?

Honest question, I'm a noob at compilers :)

<comment><USER35> Bytecode (whether x86, Java class files or this) is a far more compact and (arguably) more complete representation of the program's logic than the input source code.

Also, you haven't experienced pain until you've tried to compile C or C++ on a machine other than the author's.

</comment></comment><comment><USER36> When this is supported natively in Safari on iOS it will be interesting.

<comment><USER37> Apple's developer guidelines prohibit compiling and running anything that came over the wire, for security reasons as well as competitive ones. They could add this ability to Safari themselves, but why would they?

<comment><USER38> What do you think will be the evolution here? Surely mobile won't stay behind native-webapps forever, at some point asm.js/pnacl/something else will come in. But what?

<comment><USER37> I'll be interested to see how pepper.js performs on mobile. Certainly plenty of people have skin in the game and want to see this stuff work.

</comment></comment></comment></comment><comment><USER39> asm.js is a better answer.

<comment><USER40> What's the question?

<comment><USER10> How many layers of indirection can we put between the developer and the machine?

<comment><USER41> I'm sure there is some space left for fancy named design patterns and a template library with lambda support. You know you can't write a website without lambdas, don't you ?</comment></comment></comment></comment>


We have broken HTTP - <AUTHOR> http://gadgetopia.com/post/9236?retitle <comment><USER4> We suck at error reporting to the user. One of the legacy curses of UNIX is trying to encode all error info in "errno". Then came HTTP, which most languages try to treat as something like a file access. When there's some complex problem at the remote end, the error presented to the user has often been hammered down to some errno value that's vaguely appropriate.

This came up recently on HN in connection with GoGo WiFi on airliners, using satellite links. GoGo doesn't have the satellite bandwidth to let users view streaming video, so they block YouTube and some other sites. The problem is telling the user what's going on. They used an awful hack involving a self- signed fake SSL certificate for YouTube to try to get a coherent message to the user.

According to the IP standard, they should send back an ICMP Destination Unreachable message with a code 13, "Communication administratively prohibited". Most IP/TCP/HTTP/browser stacks won't get that info all the way up to the end user, especially the "Communication administratively prohibited" part. Even if the error code made it to the user, many customers would not interpret "Communication administratively prohibited" as "No, you can't watch Youtube because you're on an airplane and we don't have the bandwidth for that".

<comment><USER5> Why not just reroute those addresses via proxy to a static page explaining?

<comment><USER6> They're under SSL. All a reroute would do is pop up Chrome's bad cert page.

</comment></comment></comment><comment><USER7> Was HTTP ever non-broken?

I remember trying hard to get URNs to work, and proposed them for one project. They required a URN resolver, which is entire new set of infrastructure.

I tried using path segment parameters (I believe the author refers to syntax like '[http://a/b/c/g;x=1/y'](http://a/b/c/g;x=1/y') rather than '/key1:value1/key2:value2/'.) At the time (mid-1990s) the tools I used didn't support it, and I never came up with a need for them. Still haven't. The current spec (ftp://ftp.rfc-editor.org/in-notes/rfc3986.txt) says that the text after a ';' is a "non-zero-length segment without any colon" and that the contents are "considered opaque by the generic syntax." "[I]n most cases the syntax of a parameter is specific to the implementation of the URI's dereferencing algorithm."

Regarding "404 (traditionally "Not Found") means it was never here. 410 (traditionally "Gone") means it was once here but is now gone"; the spec says:

> [404] The server has not found anything matching the Request-URI. No > indication is given of whether the condition is temporary or permanent. The > 410 (Gone) status code SHOULD be used if the server knows, through some > internally configurable mechanism, that an old resource is permanently > unavailable and has no forwarding address. This status code is commonly used > when the server does not wish to reveal exactly why the request has been > refused, or when no other response is applicable.

It doesn't say anything about 404 meaning "was never here", and in fact includes the possibility that perhaps the server doesn't want to give more information.

<comment><USER8> And indeed the spec for 403 (Forbidden) includes 404 as a valid return code if you do not wish to reveal the fact that there's anything there:

 _An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found)._

<comment><USER9> Which is precisely the default behaviour of IIS.

</comment></comment></comment><comment><USER10> My problem with this article is not the general sentiment that developers should know the history of the technologies they work with, which I think is absolutely right, but instead how the author seems to put HTTP on a pedestal. It just happens to be the protocol TBL & company came up with in the early 90s for this thing that took off beyond anyone's wildest imagination. It's not some perfect work of art that should be revered. Also native apps don't make me sad. They're faster, more featureful, and have more consistent platform specific interfaces than their Web brethren. There are good reasons they exist and consumers prefer them.

<comment><USER11> This whole discussion reminds me of discussions about language evolution. Some people are prescriptivists and believe that learned language experts should determine what is and isn't correct usage. Others are descriptivists, arguing that languages are a living reflection of how they're used and that incorrect usage can become correct if and when it becomes widespread.

Similarly, we have standards boards, who are often very divorced from the realities of actually building real-world software and we also have the engineers building real-world software. Which version of HTTP is correct, the one codified by the W3C or the version codified by the engineers building Chrome, Firefox, IE, Apache and Nginx?

As a learning exercise, I implemented an HTTP server a few years ago and remember finding it fascinating that none of the popular user agents implemented the Keep-Alive header per the specification. And yet they all implemented it in a common, non-compliant manner. It made me realize that as much as I was using the spec as my guide, my implementation wouldn't be correct if I followed what it said for that header.

<comment><USER12> >Which version of HTTP is correct, the one codified by the W3C or the version codified by the engineers building Chrome, Firefox, IE, Apache and Nginx?

There is a reason why protocols are not languages. A protocol is a well- defined standard that engineers are supposed to follow. There really is no space for "descriptivists" in technology and especially in standardized protocols. What is that, the protocol is useless? Well, maybe we should come up with a new standardized one instead of bastardizing the already-existing one and creating a lot of confusion and ambiguity (which machines have a hard time to deal with).

<comment><USER13> Specs have ambiguities and bugs that may be resolved by standardizing implementations' behavior.

</comment></comment></comment></comment><comment><USER14> Maybe the simpler explanation is that HTTP/WWW was always broken. It's never been a great application platform. It's popular and universal and simple (sortof), so that's awesome, but in terms of great tech it's kind of been junk all along.

It's not like it ever was universally conformed to. It's not like there was this golden era. What would be the golden era? The web before AJAX? Geocities and Hotmail? Frames broke URLS more than almost anything. PHPNuke forums? Web apps sucked back in the early days.

Makes me think of a fun Alan Kay quote:

> The Internet was done so well that most people think of it as a natural > resource like the Pacific Ocean, rather than something that was man-made. > When was the last time a technology with a scale like that was so error- > free? The Web, in comparison, is a joke. The Web was done by amateurs. -- > Alan Kay.

<comment><USER15> Yea, the specification of status codes is cumbersome and annoying to deal with, like you're supposed to go find a list of what they are supposed to be on wikipedia and then match it up to what's going in your application as best you can. Also the PUT, POST etc stuff. It's just a pain to try to match up your application's behavior to a crusty old spec that was never that good.

It's really refreshing to code with websockets and just write an application naturally. HTTP is good for GETing static web pages and that's about it.

<comment><USER16> Way to oversimplify. HTTP works ok for some super dumb use cases. But pray tell, what's the proper way to update multiple objects at once?

Simple verbs work for simple tasks - only. There is more to life than REST.

<comment><USER5> Updating multiple resources of the same type is easy: POST to the plural form of the resource.

If you need to update multiple resources of different types atomically, then you probably need a new resource abstraction that covers both of the resources anyway. Then just POST to that.

</comment></comment></comment></comment><comment><USER17> Sounds like the OP's problem is not so much the protocol itself, as the long tail of developers using it who have no idea what it can actually do.

There are developers who do use most/all of HTTP. I'm one. I think I've used most of the obscure features he mentions, including URL parameters and all those status codes (excepting 402 Payment Required, which I've never had a need for, but I do know it exists).

Most of the features he mentions aren't very useful for browser interaction, but really shine for APIs. If you're trying to write an HTTP API, and you haven't _at least_ got to grips with all the status codes and methods, you should and take the time to understand them all and when they should be used. It's a real joy to use an API that uses methods and statuses properly. If in doubt, read the Github API docs - their API is (mostly) very good in this regard.

</comment><comment><USER18> Web developer for less than a year here, so just offering my perspective on what "new web devs" know these days. I know there are status codes beyond 200 and 404, and work with maybe a dozen in regular rotation. I know there are probably hundreds more, but until they are in more regular use I think it would just inhibit clarity to use them (just like how using less precise language paradoxically makes your prose clearer sometimes). This is sort of a chicken and the egg problem, but the paradigm could definitely shift if the marginal usefulness is high enough.

URN's I had not heard of, but the article didn't make it clear to me what problem they would solve.

Of course I know about HTTP verbs PUT and DELETE and HEAD-- is there really any web dev who doesn't? And I am pretty rigorous about using the appropriate one (unlike with status codes).

I don't have an opinion on how apps are isolated from the web and don't have interlinks between them. Don't really use mobile apps myself except utility ones like Spotify and Netflix.

<comment><USER19> You should put a bit of effort into making sure you use the most appropriate status code.

If a client isn't already aware of the code, it decides what to do based on the first number:

\- 1xx - continue receiving content

\- 2xx - finished receiving content

\- 3xx - follow redirect

\- 4xx - client error occurred, show error page

\- 5xx - server error occurred, show error page

So there is no harm in using better (but less commonly known) codes

<comment><USER20> \- 1xx - Don't Refresh Yet

\- 2xx - You Don't Need Refresh

\- 3xx - We're dealing with Refresh for you

\- 4xx - Don't Bother Refreshing

\- 5xx - Refresh, You Might Get Lucky

</comment></comment></comment><comment><USER21> Most of the good stuff here (using the full range of HTTP verbs and status codes, idempotent GET, stable URLs) is already common knowledge among web developers and built into any modern framework.

URNs are interesting but difficult to work with in practice; 402 Payment Required has been "reserved for future use" forever. Then there's the suggestion to use custom HTTP methods, which is ill-advised [1].

[1]: [http://programmers.stackexchange.com/a/193826](http://programmers.stackexchange.com/a/193826)

</comment><comment><USER22> Google cache:

[http://webcache.googleusercontent.com/search?q=cache:0PUMGvU...](http://webcache.googleusercontent.com/search?q=cache:0PUMGvUWC70J:gadgetopia.com/&hl=en&gl=uk&strip=1)

(Server is not responding at the time of writing, from two locations.)

<comment><USER23> Well, he does claim that we have broken HTTP. :)

I think the situation is improving and serious developers are using a broader range of HTTP features. Proper status code and verb usage has become very common with the proliferation of RESTful APIs.

</comment></comment><comment><USER24> > Do you know why your FORM tag has an attribute called "method"? Because > you're calling a method on a web server, like a method on an object in OOP. > Did you know there are other methods besides GET and POST? There's HEAD and > OPTIONS and PUT and DELETE.

Except HTML(5) forms do not support any methods other than GET and POST.

<comment><USER25> A form is for user input and should always be "posted" through a gateway or handler on the server side. A PUT would imply that the payload is accepted as is. Also a PUT implies that a form cannot be sent twice to the same URI after the resource on the server has been created. So PUT is basically a nightmare for user interaction.

A DELETE has no payload.

OPTIONS and HEAD make no sense for a browser, because there is no information to show to the user.

So that leaves us with POST and GET. As I already stated, POST is the best form to send user data to a server. And a form with GET is just an URI builder.

Edit: Well no, that does not leave us with POST and GET, because there are also CONNECT and TRACE. But who wants to concern a user with those?

</comment></comment><comment><USER26> > Anyone working in this space 20 years ago couldn't possibly have known of > their problems so every problem deserves a new solution.

It's worth noting that sometimes the reason for developing a new solution is to be free of the baggage that comes with all the failed attempts on the old infrastructure...

e.g. JSON-based solutions over the many attempts to use XML (XML is a capable base, but many find it unwieldy to say the least)

<comment><USER27> Well, I'm sure the creators of JSON weren't thinking of XML use-cases at the time. When it comes to solution-agnostic, self-describing, self-validating semantic markup, I'm not sure JSON-LD buys you much over RDF serialized to XML (for example).

<comment><USER28> I can speak for myself and say XML died for me when it was decided that the standard interface to it would be stream parsing. I found that stuff incomprehensible. I get the perf benefits, but it was always premature optimization for me.

You throw a JSON string at a simple parser and get an object back. That's why it won a place in my heart. Nothing prevented xml from being that except that's just not what the lib authors did. There was so much talk about XML being the One True Data Structure I think it ended up being a jack of all trades, master of none.

<comment><USER29> The problem with XML was that people tried to make it semantic. You had XML Schema (awful), and because of schema you had to have namespacing (also awful).

Take that away - plain unnamespaced tags, with no semantics beyond "this is a character sequence", common-sense business-specific tag names, and no schema - and you get something that's just as nice to work with as JSON is. And there are plenty of libraries (e.g. Jackson) that will serialize back and forth to objects. But too many people drank the semantic kool-aid and tried to autogenerate classes from schemata or other such silliness.

</comment></comment></comment></comment><comment><USER30> In my experience as interviewer, the major part of web developers doesn't know nothing besides URL in the address bar is a GET and form submission "must" be POST... Headers? What is this?! It's sad...

<comment><USER31> Who's supposed to be teaching them, though? If they don't know this stuff exists, how are they going to know to look for it? I learned it because I was always a complete RFC nerd, but I know that many developers are not like that.

<comment><USER32> Any web developer that is writing not just front-end code but also backend services or an APIs should have come across HTTP status codes and know the reason for their existence. I came across this quite early in my programming career when writing a very basic http service (it's not that long ago, I've been programming for about 10 years) and the first thing you learn are that your HTTP response will usually have headers, a body, and a status code.

In my experience, though, when working as a front end developer I've had to deal with developers (mostly in the .Net camp) who will gladly return errors with 200 OK and an xml/json object with the typical "StatusCode: xxx", where XXX is some made up error code that you'll need to reference in their application.

I believe this is because many backend developers are in web development by accident, and don't really care much about the web as a platform.

</comment></comment></comment><comment><USER33> This intrigued me:

> Don't even get me started about URL parameters. No, not querystrings – there > was originally a specification where you could do something like > "/key1:value1/key2:value2/" to pass data into a request.

I couldn't find a specification, but I did find [1] which led to [2], both of which indicate that there's an idea of parameters within the URL hierarchy itself. It seems to me that it could be useful for API versioning at least.

As to the article itself, I completely agree. The problem is, though, that there's just not enough incentive for folks to actually use the Web standards suite the way (I want to believe) it was meant to be used. How much would cost to make a fully-semantic, JavaScript-extended (but not -requiring), machine- usable website which is also adaptive and beautiful and appealing to humans? And how much benefit would one realise?

Rather than do things the Right Way, folks just hack through and do it A Way, and get on with life. I wish that it weren't so, I truly do, but it is. At this point, railing against it feels like railing against the tides.

[1] [http://doriantaylor.com/policy/http-url-path-parameter- synta...](http://doriantaylor.com/policy/http-url-path-parameter-syntax)

[2] [http://tools.ietf.org/html/rfc3986#section-3.3](http://tools.ietf.org/html/rfc3986#section-3.3)

<comment><USER34> API versioning should be done with a HTTP Header.

</comment></comment><comment> james-skemp Wow. Dublin Core. Now _that_ is a name I've not heard since around a decade ago.

It is amazing to look back to my own development history and remember that I too used to care about proper status code, using metadata elements, and the like.

But after adopting so many, and seeing so many either fail to catch on, or infighting tear them apart, or the big names pick them up and then put them aside ... it's not surprising that current developers don't think about them or don't care.

</comment><comment><USER35> For the most part, I say "1000 times yes!" I love the general idea he expresses that developers MUST take the time to understand the giants on whose shoulders they stand. To that end, I have one noteworthy point (more of a clarification) I think is worth making:

> And, technically, you're supposed to make sure GET requests are idempotent, > meaning they can be repeated with no changes to a resource. So you should be > able to hit Refresh all day on a GET request without causing any data > change.

I think it's important to note here that idempotence does not mean that the resource will never change. It means that the resource will not change _as a result of a get request_ (barring some meta requests, for example `GET /my- last-http-request`). A resource can definitely change. I think the author would agree with me but found his language there a bit ambiguous. Allow me to quote the good reverened himself, Dr. Roy Fielding:

> "More precisely, a resource R is a _temporally varying_ membership function > MR(t), which for time t maps to a set of entities, or values, which are > equivalent. The values in the set may be resource representations and/or > resource identifiers." (emphasis mine) [1]

Immediately prior this quote he references "the weather for Los Angeles today" as an example of a resource complete with its own resource identifier (perhaps GET /weather/la/today, most-to-least specific). The contents at the end of that URI will most certainly change, but they shouldn't ever change based on the request.

[1] Section 18.104.22.168 [https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding...](https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf)

<comment><USER36> To hit the most important point of what you mean by "change based on the request", this doesn't mean "changing your request changing the resource you get" (which wouldn't make any sense).

It means that the act of GETting the weather right now will never _change the weather_. (If you want to change the weather via HTTP, you'll need to do it with a method like "POST /weather/hill-valley" and a body like '{"rain": "stop"}'.)

Think of it like a getter function that gets syntactically hidden by the language: you wouldn't want "if (user.accesses < limit || user.accesses > threshold )" to have two different values for "user.accesses" based on the number of times you referred to it.

In a less ludicrous example, it also means "GET /tokens/reset/dsf46JtCb385PDs2" shouldn't log you in and invalidate the token, something that most password-reset pages fail to comply with.

</comment></comment><comment><USER37> Amen to this:

"My point is that a lot of web developers today are completely ignorant of the protocol that is the basis for their job."

<comment><USER38> What a ridiculous statement. Forgetting about the false hyperbole of "completely ignorant," HTTP is no more the basis of my job than the mixing of asphalt is the basis for a trucker's job. The basis of my job is making electronic tools for people to help them accomplish tasks. I would do that with or without HTTP (which I'm knowledgeable in thanks).

<comment><USER31> It's more like a trucker that only knows a couple of basic road signs.

</comment></comment></comment><comment><USER39> I largely understand what he's saying, in terms of misuse of the protocol. I think you're going to find those sorts of things being the case for any toolset, though. Given enough time, and enough developers, you'll eventually run into people using it an entirely different way than you initially intended, regardless of the specifications or documentation written around it.

One thing I'm not sure I agree with, though, is the mobile application "linking" he mentions. When have non-web applications ever linked? What of all of the old "desktop applications" that everyone used to use? Those don't typically link, why is there a different expectation for mobile applications? Oh, and most mobile apps do support linking (in some sense, though it's not really a primary feature). Perhaps I'm misunderstanding what he means with this.

<comment><USER40> I work at Branch (referenced in the NYT article) which tries to make it way easier for mobile devs to leverage better deep links to stuff in their apps.

Making the analogy to desktop apps is fair, but I think the better question would be why not? The URI scheme registration mechanism in Android and iOS allow the dev to create a new OS level namespace for his or her app and all 'pages' inside. For example, [http://](http://) is the scheme for browser app based addresses just as venmo:// is the scheme to address all payments or user profiles in the Venmo app. Why not leverage this technology to make app content more open and easier to access?

Now, if we could just get rid of the app store enforced install process and have apps automatically retrieved and cached, things would be a lot smoother...

<comment><USER41> > _Now, if we could just get rid of the app store enforced install process and > have apps automatically retrieved and cached, things would be a lot > smoother..._

I totally see what you did there ;). [http://xkcd.com/1367/](http://xkcd.com/1367/)

I feel the lack of linking in apps is done partially because of laziness, and partially on purpose. Most apps that are neither games nor utilities seem to be made to control the viewing experience and/or help the authors trick the users into parting with their money. Increasing interoperability seems to be counterproductive if the only reason for your app to exist is to earn a quick buck from the less savvy users.

<comment><USER40> We just discovered that one a few weeks ago - It was then we realized that we had just dedicated our lives to the premise of an xkcd comic

I disagree with your last comment as you could make the same argument for websites in general - there will always be spectrum of usefulness/scamminess. Utilities or games might not have the concept of 'pages' as a news app or a social photo upload app, but imagine being able to link to specific constellations in the star chart app, the various calculator faces of some popular calculator apps, or a user's city in Clash of Clans. It's going to be awesome.

<comment><USER42> "imagine being able to link to specific constellations in the star chart app, the various calculator faces of some popular calculator apps, or a user's city in Clash of Clans. It's going to be awesome."

I'm imagining it, and in most of those cases I'm imagining the horrible fragmentation clusterf __k that will have to be solved in Yavascript - <USER2> to "some popular calculator apps" (plural) means either providing a mess of links for the user to decide, or somehow guessing which one to show.

Two alternatives that both land in the "NAH GANNA HAPPEN" category:

* "everybody agree on a standard prefix for basic things like calculators" HAHAHAHAHAHAHAHAHAHAHA

* "allow client JS to detect installed apps" see also the detect-visited-sites-with-CSS info leakage for why this would be terrible...

<comment><USER43>
         "everybody agree on a standard prefix for basic things
         like calculators" HAHAHAHAHAHAHAHAHAHAHA

That's a URN. Unfortunately they never really got adopted. But thy solve this exact problem.

urn:calc:rpn

You click the link and your mobile phone then looks to see if any of your calculator apps satisfy that urn.

If they find any they open it up or present the user with a choice between them or open the one the user configured as their choice.

If they don't find any they check the app store or web and offer the user the opportunity to install one that satisfies that urn.

Actually this is exactly what androids intents do as well minus the app search and install. But I don't think they use urns under the hood.

<comment><USER39> I was actually going to reply something along the same lines. These sorts of services exist on both iOS and Android (can't speak to Windows Phone). Not for the provided example, but for Android, the Intents like you mentioned, and iOS has a similar concept for things like "Apps that are capable of routing/mapping" and possibly other things. Neither of these are done through the example "standard prefix," but both are through by adding some standard permission or key to your app.

</comment></comment></comment></comment></comment></comment></comment><comment><USER44> I'd say the reason why following spec on status codes has fallen out of favor is because browsers don't do anything interesting or informative with them for most users.

On APIs, I'd say it's a sin to not return proper HTTP headers, but when the end user on a web site sees a File Not Found that's 200 Status OK versus File Not Found that's 404, it doesn't really matter.

And while it matters for things like the Googlebot, over the years developers stopped caring, because delivering an attractive and descriptive status page was more important than delivering an error status and not rendering a page at all.

I'm not saying it's right, but it was largely a ornamental step in the early days of the Web, so I understand why it disappeared. If browsers proactively provided data to users about HTTP status codes, I think they'd be adhered to much more.

<comment><USER45> Returning a 404 status code and displaying an attractive and descriptive status page are not mutually exclusive. If you go to [http://www.google.com/unknown](http://www.google.com/unknown), you will get a 404, but you will also see a custom page.

<comment><USER44> Absolutely, I don't disagree. I'm saying that for most end users, there's no distinction. Status codes are for machines, but if early browsers did something noteworthy with those codes, developers wouldn't have been so quick to dismiss them in a way that is now largely habit.

</comment></comment></comment><comment><USER46> Ironically, the URL of the post is [http://gadgetopia.com/post/9236?retitle](http://gadgetopia.com/post/9236?retitle)

<comment><USER25> And?

<comment><USER46> It doesn't exactly follow the recommendations in the second link from the post: [http://gadgetopia.com/post/6346](http://gadgetopia.com/post/6346)

<comment><USER25> Yes and that is why the linked post and this post itself are bad. Both authors do not understand the principles of an URI in the context of the web.

To a client, the URI should be opaque. If a client has to start to make meaning of the contents of an URI, the server loses the ability to change its implementation (or just move resources around).

Edit: Ah, its the same author for both blog posts. That explains it.

</comment></comment></comment></comment><comment><USER47> I had to chuckle at this, its true of course that http as a standard is greatly abused and it is one of the big reasons that writing a web crawler is not just a matter of calling GET again and again.

In providing APIs for third parties that are rate limited, our APIs return a '509' error to tell you that you've exceeded your query rate. Which if you just sleep for a bit and then send a request you'll get an answer, but no, as a 'soft' error too many developers just retry it immediately which is useless. Some folks want only 3 errors, 'ok', 'dead', or 'try again' and can't deal with any more subtlety than that.

</comment><comment><USER48> I love implementing stuff like standardizations. Seriously, I love reading documentation that has lists of codes meant to concisely summarize specific frequently occurring events. I am the biggest nerd when it comes to pouring through documentation that was designed specifically with the intent to unify a common need that started off fractured.

In general though, it's just hard to know exactly when and where to implement what standardization. It's not just HTTP. The entire world of programming and computer science would be much more elegant with intelligent standardization, but it's literally a hard problem. The source of information is the hard problem. It is subject to change.

How can you standardize something that is consistently evolving, evolving to the point that it is expected that the functionality of the system is going to exceed all known expectations of it's operation and behavior? As developers, we are consistently striving to exceed our own boundaries, to do things better, more optimally, more safely, more legibly, more precisely, more correctly. Our expectations of ourselves is what screws us when we think about 'the big picture', because we apply the same model of reasoning to 'the big picture'.

Yes, we do not know what we do not know. However, we additionally do not know how to determine the difference between 'that which exists that we do not know' and 'that which does not exist that we do not know'. That is the core problem that lays underneath the lack of implementing standards, and it the reason people standardize things in the first place. Standardization prevents us from re-inventing the wheel. Standardization makes things safe. Standardization makes complex systems predictable even when information about adjacent systems are unknown. Standardization is a vehicle for implementing trust.

People get confused because there are too many words for the same thing - <USER3> many ways to describe the same things, too many languages to do the same thing, too many explanations meant to teach the same thing. Either we have to learn the hard way (by observing massive failure, or by experiencing it), or we have to hope we are implementing things the most correct way, and trust we will get there.

</comment><comment><USER49> I feel like the ignorance of developers here is overstated. Most APIs that I know of make good use of the HTTP status codes. This includes APIs from big players like Google, all the way down to small startup APIs. Sure I've seen bad ones, but I don't know that I would agree that its the majority? Maybe I've just had good luck or lived a blissfully unaware existence as a developer. Hard to say.

</comment><comment><USER50> This is just symptomatic of a saturated market. Between Google and apple there are over 2.5 million apps and probably over a billions website or something like that, all of which are using HTTP(S). On top of that, the market for developers is exceptional, because of this people are flocking to it by the minute. They are all excited to build a bridge without taking a class in engineering.

</comment><comment><USER51> One of my personal pet peeves is the misuse of the 401 Not Authorised status code being issued to logged in users. No, try a 403 instead please.

</comment><comment><USER52> What a pointless rant. Things evolve, even norms and specs.

There's a reason why URNs are not used in the code, there are not enough by themselves, if you need use URIs.

There's a reason people don't use every status code in every webapps. It's a waste of time, better spent elsewhere.

Most webapps uses more then GET.

Etc. Anyway, HTML is not broken, it's used everywhere by billions of users every seconds.

<comment><USER53> Perhaps if people understood better the technology that allows their business to operate, they wouldn't _waste time_ versioning APIs and having to re-write clients (web, mobile...) every time the server changes something!

<comment><USER52> You can't expect everyone to master everything. It's like ranting about how the whole classroom haven't got A+.

It's pointless ultimately.

The real question is how can we improve a protocol so it's better used by most people. Hence why it's evolving. Nothing should be set in stone forever and then expect everyone to comply to it or die.

</comment></comment></comment><comment><USER54> You know what really bothers me? It's not the abuse of HTTP status codes. It's the closed nature of apps.

How many of us got our start in web development by viewing the source of the page? By looking at how others did things? Hell, I still do that now.

Apps are the Microsoft of the Internet -- closed, proprietary and secretive. Open source and github has helped this some, but meh.

</comment><comment><USER55> > ...developers tend to think they can solve every problem, and they're pretty > sure that nothing good happened before they arrived on the scene. ... they > feel no need to study the history of their technology to gain some context > about it.

So, so true. In fact, this happens depressingly often when "technology" is defined as narrowly as "the app a developer is working on" and "history" is as short as "a month ago".

This has always happened, but it feels like it's gotten worse since "agile" became widespread. As if the principle of YAGNI ("You Aren't Going to Need It") has been turned into a poisonous assumption that nobody before you _could_ have put any thought into the future. Rather than trying to understand the natural extension mechanisms that might already be in place, people just jump in and write more special-case code.

</comment><comment><USER56> The current state of the web is the result of too many cooks in the kitchen. Nobody is ever willing to stand up and say _no_ to countless new additions that often simply replicate old behavior, or don't add anything compelling or likely to ever be used by others. We even have outright gags in the official specs, like the 418 response.

It's already too late to make HTTP something sane. What we need are developers who understand and appreciate simplicity and minimalism, to make something awesome with a chance of actually catching on. (Please don't xkcd/927 me.) And they'll have to be fierce in protecting it against third-party extensions (which may not even be possible with something this popular.)

That's unlikely to happen, so I guess we'll just keep playing this perverted game of Jenga ad infinitum.

<comment><USER57> Ha, I had to look up 418.

418 I'm a teapot (RFC 2324) This code was defined in 1998 as one of the traditional IETF April Fools' jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers.

[http://tools.ietf.org/html/rfc2324](http://tools.ietf.org/html/rfc2324)

<comment><USER58> Sorta related, The HTTP2 Error Code of ENHANCE_YOUR_CALM strikes me as a joke because of the name...

[http://http2.github.io/http2-spec/index.html#ErrorCodes](http://http2.github.io/http2-spec/index.html#ErrorCodes)

A quick Google shows that it's previously just been used by Twitter to demonstrate rate limiting.

</comment></comment></comment><comment><USER59> Also see the discussion here - [http://www.reddit.com/r/programming/comments/2rzlay/we_suck_...](http://www.reddit.com/r/programming/comments/2rzlay/we_suck_at_http/)

</comment><comment><USER60> I've heard a couple of times that requests coming from JS "need to get a 200" in order to see the response data at all. Now, I've never worked with JS myself, but to me this sounds more like a badly-designed library problem, but it keeps becoming an issue every time I push for an API without broken error codes.

<comment><USER61> Just looked this up and you're right: in Firefox 3.6, there's a bug where the XMLHttpRequest response body won't be populated by Firefox if the status code is 400. Seems like a little-known bug that has been vaguely referenced elsewhere.

[http://bugs.jquery.com/ticket/7868](http://bugs.jquery.com/ticket/7868)

[http://stackoverflow.com/questions/5884286/jquery-ajax- with-...](http://stackoverflow.com/questions/5884286/jquery-ajax-with- non-200-responses)

<comment><USER62> That's a regression from 4 years ago. You can get the response body in any status code in JavaScript.

</comment></comment></comment><comment><USER63> I liked the author's comment about using canonical URLs (with a link to another of his articles on this subject). This is something that I have been intending on doing for a while - I just pushed changes supporting canonical URLs to my main 3 web portals.

</comment><comment><USER64> HTTP is too flexible not to theoretically break but in practice it can be used and abused and still deliver.

</comment><comment><USER65> As a protocol, it works perfectly well for transporting hypertext, what's the problem?

<comment><USER66> Implementations.

</comment></comment><comment><USER67> It sounds like this guy just learnt about HTTP details.

</comment><comment><USER68> HTTP comprehension and usage are critical. People wonder why websites don't perform and api are difficult to program for. I have seen that developers have this weird need to create your own method and means of communicating errors. Even ws-* developers don't use soap errors. That is what we are talking about mostly in this article non-standard messages/state.

Treating your application and data as resources (REST is the style of the web) and leveraging the power of HTTP so powerful. You are not a crabby old man. If you do count me in, 33 years old. I could make a career consulting and only fixing http and resource abstraction/usage problems.

IMO though educating our fellow developers on HTTP is easy compared to the REST HATEOAS constraint.

<comment><USER69> > I have seen that developers have this weird need to create your own method > and means of communicating errors.

Developers ignore most of the status codes because they introduce unnecessary complexity on both ends (client and server) and do not always map well with the application logic. With JSON payloads, HTTP is used as a "light vehicle" to carry the application logic. Since the payload is going to be specially interpreted anyway, I don't see a benefit in cramming legacy HTTP cruft in the headers and in status codes.

The really annoying thing is the web server spitting out HTML on error conditions instead of the expected JSON.</comment></comment>


Show HN: Lunacy – We hacked Sketch file and created a viewer on Windows - <AUTHOR> https://icons8.com/lunacy <comment><AUTHOR> Today we are very excited to announce the release of Icons8 Lunacy 2.0: Free viewer for Sketch files on Windows

Over the past month Igor, developer of Lunacy, has been working on fixing bugs reported by the community, implementing new features, and introducing new UI for the application.

In Alpha version you could:

\- Open .sketch files

\- Export images

\- Inspect layers, measurements, styles, fonts, colors, etc.

\- Generate CSS for layers

In the new release we added:

\- Symbols support

\- Fonts auto search in Google Fonts

\- Shadows/Blur effect support

\- Offsets between the objects are now displayed

\- Selection of multiple elements

\- Complete UI design overhaul

Icons8 Lunacy doesn't require internet connection, thus you can work from anywhere. And have we mentioned it is completely free? :)

We want to know what you think of Lunacy. We're looking forward to hearing your feedback and to answering your questions!</comment>


The $8 key that can open New York City to terrorists (2015) - <AUTHOR> http://nypost.com/2015/09/20/the-8-key-that-can-open-new-york-city-to-terrorists/ <comment><USER2> Duplicate of [https://news.ycombinator.com/item?id=11275505](https://news.ycombinator.com/item?id=11275505)</comment>


Open Graph protocol - <AUTHOR> http://opengraphprotocol.org/

<comment><AUTHOR> ...also, google's not going to take this lying down ;)

Why I say that... Open Graph is part of Facebook's strategy to use its 400M-user social network as leverage to take over indexing and navigation of the web, and serve ads with it.

Navigation of the web has been almost entirely Google's territory, because of Search (which also equals 90% of their revenue, from AdWords ads).

Therefore, Google has to counter Open Graph somehow...</comment>


FriendFeed Traffic Is Actually Up Since The Facebook Deal - <AUTHOR> http://techcrunch.com/2011/01/02/facebook-friendfeed-turkey-2/

<comment><USER2> FriendFeed is really a special place in the narrative of Internet sites with large social networks. It introduced so many new ideas and was the fastest and easiest way to get news and see all the ripples of information passing online. You would see the beginnings of viral content early on FF better than anywhere else, and its commenting and sharing features are unreplicated anywhere else. Was truly an amazing place when I used it heavily for 2 years back in 08. I did notice a heavy influx of Turkish and Italian users in the latter days of pre-acquisition era. Still a pretty good tool, but its best features were the people to follow who would help curate the news sources for you and have discussions, but most of the old English-speaking guard have left unfortunately.

</comment><comment><USER3> Ok, I am really getting sick of TechCrunch spinning off articles from Quora. It was cute with the Netflix stuff (<http://techcrunch.com/2010/10/04/quora- netflix/>). Then came the AOL CDs (<http://techcrunch.com/2010/12/27/aol- discs-90s/>), now this is just too easy. Come on guys, you can do better. I am not saying this isn't good stuff, but just that your loyal readers notice these patterns.

If you are going to continue this, at least contribute back to Quora more.

</comment><comment><USER4> Isn't the difference between FriendFeed and Facebook is that FriendFeed is _actually_ innovative?</comment>


OpenBSD Foundation Announces Gold Sponsor DuckDuckGo - <AUTHOR> http://undeadly.org/cgi?action=article&sid=20160503085227 <comment><USER2> Still the best OS if you just want to get work done.</comment>


Nasa Image and Video Library is now open and free - <AUTHOR> https://images.nasa.gov/ <comment><USER2> When the Curiosity rover took a "selfie" on Mars, I got a giant vinyl print of it to hang on my wall. I've been recently downloading all the images from the Nasa Apollo Journals where you can see every single frame they took in orbit and on the moon. There are some absolutely stunning black and white photos, I wish I could get my hands on some replica negatives and do a silver print.

<comment><AUTHOR> Could you link to the selfie, please?

</comment></comment><comment><USER3> Here is some good news for a change that can be celebrated and enjoyed.</comment>


Why ChatRoulette Fails - <AUTHOR> http://scienceblogs.com/cortex/2010/02/chatroulette.php

<comment><USER2> I'm not sure where the submission title comes from? Sure, compared to the marketing hype, the OP acknowledges that ChatRoulette _"proves to be a profound disappointment"_ , but then he turns that into a discussion of its alluring offer of internet-based social friction, worthy of a Whitman poem.

<comment><USER3> Submission title is bizarre. No talk of failure, let alone "why".</comment></comment>


Windows 8 Tablets: The most successful tablets ever. - <AUTHOR> http://www.zdnet.com/windows-8-tablets-the-most-successful-tablets-ever-7000005805/

<comment><USER2> Riiight. This is, at best, uninformed astroturfing - "I mean, windows is windows is windows, so it's gonna be the same thing like desktops, right?" To quote directly: "And, since Windows is such a versatile platform and uses standard hardware, it's likely that you can run virtual machines on it with a Type 2 Hypervisor or dual boot it with Linux." - perhaps someone should tell the poor guy that there's also the tiny little issue of hardware and drivers?

</comment><comment><USER3> Sentence number two pretty much sums up the article: "Though I haven't been lucky enough to review one yet, I feel as if they'll take the market by storm..."

Pretty sure ZDNet is trolling us, and if so good for them because I fell for it and clicked.</comment>


Twistronics: superconductor prototypes discovered after twisting graphene sheets - <AUTHOR> https://www.nytimes.com/2019/10/30/science/graphene-physics-superconductor.html <comment><AUTHOR> From the article: Recently, physicists from the Massachusetts Institute of Technology discovered that stacking two sheets of graphene and twisting a small angle between them reveals an entire new field of material science – twistronics. In a paper published in Nature, researchers have taken a look into this new material, known as the magic-angle twisted bilayer graphene. By modifying the graphene's temperature, they were able to cause the material to shift from behaving like an insulator to transforming into a superconductor.

</comment><comment><USER2> Is this the same phenomenon discovered last year by Yuan Cao et al?

[https://www.nature.com/articles/nature26154](https://www.nature.com/articles/nature26154)

<comment> david-gpu From TFA: "What M.I.T. saw, we reproduce," he said. "But on top of that we observe many more states, which most likely in his case were not seen, because of the dirty devices."

</comment></comment><comment><USER3> [http://archive.md/hU8Zg](http://archive.md/hU8Zg)

</comment><comment><USER4> Don't remember where I saw that saying, but ...

"Graphene. There's nothing it can't do, except leave the lab"

</comment><comment><USER5> If anyone ever managed to produce and manipulate graphine in a controlled way and at industrial scale it will revelationise whole economic sectors. U til then though...

<comment><USER2> Saw this article recently about a Cambridge spin-out making 8" wafers of graphene: [https://www.cam.ac.uk/research/news/cambridge-spin-out- start...](https://www.cam.ac.uk/research/news/cambridge-spin-out-starts- producing-graphene-at-commercial-scale)

</comment></comment><comment><USER6> Url changed from [https://hackaday.com/2019/12/27/magic-angle-twisted- bilayer-...](https://hackaday.com/2019/12/27/magic-angle-twisted-bilayer- graphene-yes-thats-the-scientific-name/), which points to this.

<comment><USER7> Does it really make sense to change the URL from a non-paywalled site to a paywalled one? The NYT version doesn't even load a hyperlink that I can use to read the Nature paper, while the hackaday site loads and I can follow links through to the paper and to NYT.

<comment><USER6> If there's a paywall workaround, it's ok. Users usually post workarounds in the threads. There's one in this thread.

No question the paywalls suck, but until there's an industry-level solution, this is the best of the bad options we're stuck with. There's more explanation here:

[https://hn.algolia.com/?query=by:dang%20paywall&sort=byDate&...](https://hn.algolia.com/?query=by:dang%20paywall&sort=byDate&dateRange=all&type=comment&storyText=false&prefix&page=0)

[https://news.ycombinator.com/item?id=10178989](https://news.ycombinator.com/item?id=10178989)</comment></comment></comment>


Cash-strapped BART considers spending $227M on new downtown Oakland HQ - <AUTHOR> https://www.mercurynews.com/2019/09/06/cash-strapped-bart-to-spend-227-million-on-new-downtown-oakland-headquarters/ <comment><USER2> Maybe they should buy PG&E instead?</comment>


Atlassian Acquires StatusPage - <AUTHOR> https://techcrunch.com/2016/07/14/atlassian-acquires-statuspage/ <comment><USER9> I really love the execution. Neat, slick and they even had the luxury to be open about it in their blog. They attacked a simple-to-understand but real problem, on a niche, making something people wanted to have and not wanted to do. They built the right integrations...making money since the beginning, increasing revenue per user and overall revenue... They probably made lots of mistakes , but according to public information and taking the time to analyze it with some prospective, they did (almost) everything right. Following their traction and revenue, they must have sold for a good price as Atlassian really needs such products to renew their platform and they have the portfolio of customers Statuspage would have tried to acquire. Great story.

</comment><comment><USER10> This acquisition doesn't fill me with confidence for the future. StatusPage was a clean, simple, and intuitive service. Atlasssian's software is the opposite of clean, simple, and intuitive.

<comment><USER11> Having used many different bug tracking, help desk, and ticketing softwares… Atlassian does a dam good job. Totally customizable screens, fields, and workflows with a modern UI. A decent webservice API I've integrated a few external tools into without much difficulty. I've also written a few gadgets and plugins and received a decent amount of attention through their plugin marketplace. Maybe the admin that setup your install or business workflow did a bad job?

I don't think you say the same about other competitors right now… ServiceNow? HP SMS or ALM? ClearQuest? I've used those and if you consider Atlassian terrible, I'm not sure what words you would use to describe them…

<comment><USER12> > Maybe the admin that setup your install or business workflow did a bad job?

I think this is key. There's so much customization allowed that its easy to get wrong. Your experiences can vary drastically between a well configured instance and a poorly configured one.

<comment><USER13> I'll also add it's not always obviously wrong when it's setup.

For example, of course only QA people can use "Testing passed" transition. Of course there should be x, y, z fields filled out to be able to create the ticket. Well we're at it, let's make sure only the product manager can close a ticket with 'wontfix', and only the release manager can change a fixversion.

This is a really common problem with any workflow tool, where well-intentioned control points get in the way of actually Getting Things Done, both from the perspective of not thinking through all the complex scenarios (what? I have to fill out 5 fields before I can close this as a duplicate??) and from not trusting your employees (don't worry, a jr. dev is not going to re-assign a fix version even though they can -- or at least, they won't do it twice).

<comment><USER14> For you, there is Github issues. Have fun, cowboy.

<comment><USER15> Having used HP Quality Centre, JIRA and Team Foundation, I think your snark is unwarranted and there is a middle ground to be found between very basic issue tracking and something completely overbearing like QC.

<comment><USER16> It's been years and HPQC still gives me nightmares.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> I remember when I was doing a talk in Melbourne, another developer told me what he didn't like about Atlassian was that they essentially only had one product (was it Jira? or Confluence? can't remember) and almost everything else in their offering set; they bought from other people and re-engineered to fit into their product line.

Having administered, Jira, Confluence and Bamboo servers (all with slightly different installation steps, logging and means to connect to LDAP), what he said made sense.

That being side, I really like Confluence. It's an amazing wiki, even though it's a bit expensive (although they do have free open source project licenses) and kinda resource hog.

<comment><USER18> Their biggest product is JIRA followed by Confluence. Let's look at acquisitions vs internal developments:

\- 2003: JIRA - In-house

\- ~2004: Confluence - In-house

\- ~2007: Fisheye, Crucible (code analysis) - <USER6>

\- ~2008: Bamboo (builds) - <USER6>

\- 2010: Bitbucket - <USER6>

\- 2011: SourceTree - <USER6>

\- ~2012: Bonfire (JIRA Capture - screencast bugcatcher) - In-house

\- ~2013: HipChat - <USER6>

\- ~2013: Stash (BitBucket Server) - In-house

\- ~2013: JIRA Service Desk - In-house

\- ~2014: JIRA Portfolio (capacity management for Agile) - In-house

\- 2014: Wikidocs, Doctape - <USER8>

\- 2015: BlueJimp, Hall, StatusPage - <USER8>

But what's the right way to start a product today? It's easy to make big bets when you're a start-up, but when you already own several products, you're exposing the brand with every decision. If a product doesn't find its market fit on day #1, if you don't support every combination of platforms, if it really fits a niche but if you also expose the product to customers who were not the initial target, if the pricing is wrong, if it doesn't fit a certain usecase => Your brand is exposed.

I understand the trend to reach growth by external acquisitions, then achieve earnings by scaling the product to the Atlassian size. It's easier to explain it to the market, plus you've already proven the features match the customer case.

Because something else in in-house at Atlassian: Going from Server products to cloud products with the same codebase (a real technological performance), developing the Plugins 2 system and the Atlassian Marketplace, developing an internal PAAS platform, hosting microservices [1], developing a uniform graphic design and graphic library, developing the sales, creating a big conference for their products in CA (named Summit), creating the developer conference (AtlasCamp in Europe), the marketing machine and relationships with journals. Let's give credit to the workers of the shadow: Most of the work that's needed to make great products aren't features.

Maybe, after all, it's a company whose core business became to bring features from niche/luxury/early adopters to enterprise. They shorten the path of good ideas from hackers to IBM-style customers. It's important to us, developers, because they helps migrating big old companies like banks and government to new methods. The features of the software you put in are important, but what's more important is how to massively develop adoption. Man I'd love to be a PM for Atlassian ;)

[1] [https://www.atlassian.com/atlascamp/2016/archives/build- amaz...](https://www.atlassian.com/atlascamp/2016/archives/build-amazing-add- ons/the-art-of-paas-lessons-learned-running-a-platform-for-hundreds-of- microservices0) \- and you can look at their other developer conference videos too.

<comment><USER19> Nice overview! Don't forget Bitbucket Pipelines (in-house), which is intended to replace Bamboo Cloud:

[http://blogs.atlassian.com/2016/05/introducing-bitbucket- pip...](http://blogs.atlassian.com/2016/05/introducing-bitbucket-pipelines- beta-continuous-delivery-built-within-bitbucket/)

(Atlassian employee here)

</comment></comment></comment><comment><USER20> Their original Show HN: [https://news.ycombinator.com/item?id=5401470](https://news.ycombinator.com/item?id=5401470)

<comment><USER21> Thanks for the link. It is great to see how things move from the early beginnings to an acquisition

</comment></comment><comment><USER22> The ability to subscribe to other companies' status pages has saved me so much time and headache. StatusPage has done something awesome here, for all the people that rely on various services moreso than the service providers themselves. Congrats to the team!

</comment><comment><USER23> "Adding a service like StatusPage, which launched three years ago, seems like a natural fit for Atlassian."

Why is this a natural fit for Atlassian? Not being snarky, I just don't see how this is any more a natural fit for Atlassian than lots of other companies that provide picks-and-shovels to the software builders of the world.

<comment><USER24> Jira goes down a lot. Maybe it helps you notice faster?

<comment><USER25> Must be a problem with your installation. I've used Jira at 2 separate companies and it never went down (it was purposefully restarted a few times a year to apply updates).

Edit: I see that HipChat's reliability is a big issue for several posters, maybe your installation has that. The ones I've used were fairly basic.

</comment></comment></comment><comment><USER26> As a happy StatusPage user, I am worried about this acquisition. Been more and more frustrated with Atlassian and recently we had to move away from HipChat due to multiple issues (constant downtimes).

What are the good alternatives to StatusPage?

<comment><USER27> We use Cachet[1], an open source alternative. We checked out many status page services out there, but found it hard to understand how some of them (web apps with a handful of pages) were more expensive than our accounting system or project management services we subscribe to?!?

[1] - [https://cachethq.io/](https://cachethq.io/)

<comment><USER28> Status pages are best hosted offsite, which means status page companies can easily justify higher prices since the alternative is to run your own servers exclusively for the status page (can't just throw the status page software on your app server).

I'm skeptical that running Cachet on your own servers would be cheaper than StatusPage's smallest plan, especially if you have any kind of redundancy in place.

<comment><USER27> Our main stack is on Amazon AWS (West Coast) and we run Cachet on a $5/mo Digital Ocean Droplet on the East Coast for redundancy. Took about 30 minutes to set up Cachet on the DO VPS.

That is enough redundancy for our little bootstrapped web app until we are large enough to be able to afford something better.

<comment><USER24> And for another $5 you could likely round robin dns a vpn in Europe. Being cheap is fun.

</comment></comment></comment></comment></comment><comment><USER29> Official blog post here:

[http://blog.statuspage.io/joining-the-atlassian- family](http://blog.statuspage.io/joining-the-atlassian-family)

</comment><comment><USER30> Seems like the perfect acquisition for handling HipChat's downtime.

<comment><USER31> Ouch.

I know snark is generally frowned upon, but HipChat and hosted JIRA/Confluence downtimes have been serious issues for us.

<comment><USER32> Not limited to just those products, we have issues with BitBucket.

One example: it can sometimes take > 5 mins to merge a PR.

<comment><USER33> How many open PRs do you have targeting the branch you're merging into it? We heard through the grapevine that there are serious performance problems if you have more than 60-80 or so.

The solution for us was to decline those old PRs.

<comment><USER34> That's concerning. We use GitHub with a monorepo and have 462 open PRa without issue.

</comment></comment></comment></comment></comment><comment><USER35> Congrats Scott & the StatusPage team! I interviewed for a position with StatusPage at one point (ended up going with a different company), but I have huge respect for the product and the team.

</comment><comment><USER36> I'm surprised they sold. This seems like a fantastic business.

<comment><USER37> Seems like self-employment, not business, which gets cut from the bill the minute the next down cycle shows.

<comment><USER38> There is such a thing as so cheap it's not worth cancelling. These status pages are a perfect example.

</comment></comment></comment><comment><USER39> Software for people who make software for people who make software for people who make software.

</comment><comment><USER40> Congratulations. I enjoyed the clear, transparent blog post, although my fundamental question "Will they shut down the service in the mid-to-long term or force us to become an Atlassian customer?" took some time to get an answer to.

I also felt their blog post was all about their journey, which while interesting doesn't really present any value for us as a customer. It would have been nice to know why the acquisition is in the customers' best interest rather than only the founders' (of course both are important).

</comment><comment><USER41> Congrats guys! Very happy for you!!

</comment><comment><USER42> Congrats Steve, Scott, and Danny!

</comment><comment><USER43> Off topic - What are some alternatives to JIRA?

<comment><USER44> Which subset of functionality do you need?

Issue tracking? Kanban? A means to align corporate initiatives with dev effort? Defect tracking with built-in links to commits and vice-versa?

<comment><USER43> Oh right, thanks for asking. Issue tracking and Kanban mostly

<comment><USER45> I'd suggest Phabricator[1]. Although it was quite hard to use at first, after few months we really love it!

[1]: [http://phabricator.org/](http://phabricator.org/)

<comment><USER27> Phabricator looks great, but can the end user edit the menus to change the spelling of Maniphest, Phriction, Conpherence, Phame, Pholio etc.?? That's cute for 5 seconds but then would drive me crazy if I had to see that on a day to day basis.

<comment><USER45> I don't think you can change, as they consider these component names to be an app name (the same way as JIRA has Bamboo, Confluence, etc.)[1] In the actual UI they do include description on what each one is[2] and you can activate Serious Business Mode[3] to tone down all other jokes in the UI.

Everyone in our development team eventually get used to the names, and everyone loved all the little jokes, so we leave the Serious Business Mode off, though.

On the other hand, you can customize the sidebar, deactivate stuff the team is not using, and such. Default install is definitely overwhelming.

[1]: [https://www.quora.com/Phabricator-Why-is-the-Browse- feature-...](https://www.quora.com/Phabricator-Why-is-the-Browse-feature- called-Diffusion-and-not-just-Browse)

[2]: [https://files.grid.in.th/iXMhtQ.png](https://files.grid.in.th/iXMhtQ.png)

[3]: [https://secure.phabricator.com/book/phabricator/article/tone...](https://secure.phabricator.com/book/phabricator/article/tone/)

</comment></comment></comment></comment></comment></comment><comment><USER46> I wonder when Atlassian will buy Jetbrains.

<comment><USER47> Let's hope never. Jet Brains make amazing software. Would suck for them to be aquired by the likes of Atlassian. Their products would turn to rubbish.

</comment></comment><comment><USER48> Could'nt some static pages ( based on templates ) hosted on S3 ( with its high reliability ) do the job?

<comment><USER49> No. You also need something that responds to events and reports on them. Statuspage integrates with pingdom, new relic, and datadog.

</comment></comment><comment><USER50> If you're worried about this, you can always use the other status page site that many other startups and large corps use: [http://www.status.io](http://www.status.io)

</comment><comment><USER51> Congrats!

</comment><comment><USER52> Question: If my web service is down, how do my customers know ex-ante to check in with statuspage.io for more information?

</comment><comment> martin-adams I wonder if this means I'll be able to unsubscribe to the Atlasssian SMS notifications. They make is so easy to subscribe, but no details how to unsubscribe.

<comment><USER53> Reply to the SMS message with with "STOP"

<comment> martin-adams I think it would be nice if there were clearer instructions. Plus, I'm hesitant as I don't know if texting 'STOP' to a +1 (US) number from the UK.

I've just looked up the cost, it would be about £0.20 to send it.

I did tweet them about it a while ago, but I din't think it really made sense.

[https://twitter.com/Martin_Adams/status/702074369296769024](https://twitter.com/Martin_Adams/status/702074369296769024)

<comment><USER53> Ahh. Sorry about that. Shoot us an note to hi at statuspage.io and we'll get you taken off. No text messaging necessary :)

<comment> martin-adams That's okay, I sent the STOP text and looks like it's done the job. Thanks for replying!

<comment><USER53> no problem!

</comment></comment></comment></comment></comment></comment><comment><USER54> as a customer of many companies who use status page, i do not understand it at all. this is just a nice looking page with some history to it?

most of my encounters with status pages have outdated information such as i am checking your page because i think you are down, but you dont list that you are down, yet. or when they are having a problem, there's a very tiny indicator and somewhat useless message.

what could this possibly bring atlassian that they couldn't build themselves?

<comment><USER28> StatusPage is well known and has many customers, so I think this is more about buying the business than merely the product.

</comment></comment><comment><USER55> 'Outside Your Infrastructure, Always Up'

AWS has outages too, also statuspage.io own site reports, Hosted Pages Uptime 99.969%

99.969 != always.

Pricing also isn't too shabby, Enterprise starts at $1499/mo. Billed annually.

For small 18.000$ a year, one should be able to setup your own external monitoring, with email, Facebook, twitter and what not for hooks to update your users of the service status where the sky is the limit, not the limits statuspage.io sets for your account.

<comment><USER56> Enterprise pricing is not about being cheaper than it would be for you to do it yourself. It's about you simply not having to do it yourself. You might be an organization that only employs 5 developers. It's much easier to pay a small fraction of what you pay one of them than it is to pull 1-3 of them off of what they're working on and have them build you a buggy implementation of the same thing that won't be ready for many months.

<comment><USER55> It is always easier to pay somebody else to do it? Whats the point you try to make? I never mentioned it is cheaper to do it yourself. And enterprise is certainly not for teams of 5 people, 'Starts At 50 Admin Members'

Setting up the statuspage.io, monitoring it, keeping things as they should, adding new stuff to monitor thats not a task one of those 5 will be doing regularly? And what if he does a poor job at that? You end up with what you say, the same buggy level of monitoring. So what _is_ the excuse not to make your own and pay significant amounts of money to a third party?

I say 18.000 is a lot of money for a service that reports your outages (good 3 month salary here, and in three months one can code a lot). And if you do it yourself you have all the freedom of choice how you monitor what you monitor how you report to your users instead of relying on the options statuspage.io offers, there is no limit

And why would your own monitoring be more buggy then some setup a third party deems to be ideal? You can make a perfect fit, gives you another view on your own products etc. Full control is key, in house solutions, not saving money.

<comment><USER56> > _And enterprise is certainly not for teams of 5 people, 'Starts At 50 Admin > Members'_

I said 5 _developers_. My first job was on a team of ~12 developers for a company with 30,000 employees. Developer time was gold and as such the company often purchased products that we probably could have built in house _given sufficient time_.

> _And if you do it yourself you have all the freedom of choice how you > monitor what you monitor how you report to your users instead of relying on > the options statuspage.io offers, there is no limit_

If you need something an off-the-shelf option doesn't offer than you wouldn't be considering it in the first place. If you have truly odd requirements you're going to be forced to build your own anyway.

> _And why would your own monitoring be more buggy then some setup a third > party deems to be ideal?_

StatusPage's Show HN was a little over 3.5 years ago. There's no way you can build something _less buggy_ in 3 months. This is a perfect example of not only developer hubris and "Not Made Here" bias, but the problem of trying to estimate the time to walk up the coast[0].

[0] [https://www.quora.com/Why-are-software-development-task- esti...](https://www.quora.com/Why-are-software-development-task-estimations- regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe?srid=oqU)

<comment><USER55> 12 devs on 30.000 employees? This was an (IT related) company that would be a possible customer of statuspage.io? I have to admit i'm very curious what company, industry this was/is or services were provided. It's a strange balance 12 over 30000

And im curious if* you wouldn't have liked it more if you did have more time, resources, colleague to have had the chance to develop those things in house, yourself. And having another product to sell instead of buying a service from a (potential) competitor?

Also i doubt they have been coding for 3.5 years, and if their show HN was 3.5 years ago, very nice promotion for them. But that doesn't say anything about the quality of the product. From what i have been reading over the years from their development they are just integrators of already existing technology. So if you want me to integrate APIs for 3 months, i think i can get quite a long way.... by myself in the evening hours and weekend even.

They started with outsourcing most of their services used (mailgun for mail, twilio for sms, etc etc), so i rather develop something myself, (and yes in 3 months i can integrate a lot of 3rd party services via APIs). So if you prefer to OUTSOURCE, your service to a party that outsources their services again, and find this of a higher quality of service then* writing your own (which give you options to resell that product etc), then i think we just have different view of what quality is.

Nonetheless, weekend is coming, hope you have a good weekend :) probably in case of reply will read it only after

</comment></comment></comment></comment></comment><comment><USER57> I usually use "[http://www.downforeveryoneorjustme.com/"](http://www.downforeveryoneorjustme.com/").

If your site's back end is down, the site itself should be saying something intelligent. ("Ngnix timeout", or Cloudflare's error message blaming the site server, is kind of lame, but it's something.)

<comment><USER58> Cloudflare will serve any page you like during an outage.

If you pay them.</comment></comment>


How Much Time is Necessary for Website Testing - <AUTHOR> http://www.newfangled.com/months_would_be_nice <comment><USER3> As much time as is necessary for "Website Building".

If you bring in your Quality (or "testing") people after the inception - <USER2> put them in a position of disadvantage (always catching up, and always behind) for the rest of the project; and if you do not empower them sufficiently you are just paying lip service to quality and crossing a line of the list -- and are very likely to endup like this project did.</comment>


Mining social networks - <AUTHOR> http://www.economist.com/node/16910031

<comment><USER2> Interesting. Sadly it does not mentions any practical tools for doing social network analysis:

Here are few that I know:

For small networks (up to a million or two million nodes such as Wikipedia Link graph from 2009)

Following libraries provide code to handle and manipulate Network datasets:

1: SNAP by Prof. Jure Leskovec [ <http://snap.stanford.edu> ] written in C++

2: Networkx by Lanl [ <http://networkx.lanl.gov/> ] written in Python, esp. good for fast prototyping

There are few Databases for storing networks, e.g. Neo4J <http://neo4j.org/> .

Additionally there is a Graph Processing Language called as Gremlin

<http://wiki.github.com/tinkerpop/gremlin/> .

For Large networks with millions and billions of nodes, one can use Hadoop / Map-Reduce or Apache Hama [still in nascent stage]. Google has a special system known as Pregel which it uses to perform scalable computations over large networks.

<comment><USER3> I'm watching one of the 2 hours videos from the Stanford professor. He looks like a college freshman! No offense intended.

Do you have any resources on how to use these tools (especially the python library), and examples of implementation? I'm interested in learning more and using these tools on real data, but don't necessarily want to spend the time learning all of the theory behind it.

<comment><USER2> Yup he is young, he did a post doc for a year at Cornell [under Prof. Kleinberg] after his PhD, and directly became Asst. Prof at Stanford.

Well you can start with reading this book <http://www.cs.cornell.edu/home/kleinber/networks-book/> for overview, regarding application of these techniques are considered you can look for papers at recent WWW, NIPS,ICML conferences. The most popular and well studied areas are Link Prediction and Community Detection. The SNAP library comes with some good example code. You can also have a look at Divisi project at MIT Media Lab if you are interested in reasoning/ analogy over the networks.

For real datasets, there are a lot of encyclopedic datasets such as Wikipedia / DBPedia /Semantic Web/ Music Brainz, as well as social ones such as Twitter follower network dataset. If you are in a university, you can even get full Web Graph from Yahoo [for research use alone].

</comment></comment></comment><comment><USER4> So this was back in 2008, but I read this from Bruce Schneider:

[http://www.schneier.com/blog/archives/2008/10/data_mining_fo...](http://www.schneier.com/blog/archives/2008/10/data_mining_for_1.html)

<quote>But the authors conclude the type of data mining that government bureaucrats would like to do--perhaps inspired by watching too many episodes of the Fox series 24--can't work. "If it were possible to automatically find the digital tracks of terrorists and automatically monitor only the communications of terrorists, public policy choices in this domain would be much simpler. But it is not possible to do so."</quote>

So did something change in the last two years? I mean Palantir is making a crap ton for presumably something similar.

Was this ever a problem, or was it overcome?

<comment><USER5> "Was this ever a problem, or was it overcome?"

The problems Schneier is talking about have very different characteristics than the ones in this article. So the problems Schneier is talking about are still very real. But solving little pieces of the problem is definitely possible, especially with a good amount of human mediation.

<comment><USER6> Human mediatiation is key. Skilled intelligence analysis made by well versed operators. even then it is very hard.

As one intelligence analyst once told me " it is looking for a needle in stack of needles"

</comment></comment></comment><comment><USER7> Reading a social network analysis textbook, one is struck that all the examples involve rigorous data collection by social scientists with clipboards. Hundreds and thousands of hours of work for a small graph. Modern social networks have given us an abundance of data against which to leverage a backlog of techniques that were previously constrained by manual data collection.

Phone companies use this stuff in ways that may be unethical, but it can just as easily be used in ways to empower you to leverage your own network. There are exciting potentials we are just beginning to see.

</comment><comment> loup-vaillant So, phone companies spy on us to make money, help the police (probably without a warrant), and spread propaganda.

<sarcasm> How surprising. </sarcasm>

Seriously, it's not like we couldn't have foreseen: [http://www.softwarefreedom.org/news/2010/feb/01/freedom- clou...](http://www.softwarefreedom.org/news/2010/feb/01/freedom-cloud- software-freedom-privacy-and-securit/)

</comment><comment><USER8> This is why facebook is worth billions. They can mine so much social data and deliver targeted ads to the proper influencers.

</comment><comment><USER9> does anyone know of a secure, non-free alternative to gmail , where one wouldn't have (as much) to worry about having your privacy violated?

<comment><USER10> Keep in mind that your privacy is only as secure as that of your correspondents. I kind of gave up on the idea of keeping email private when I realized that most of the people I write are non-techy and use GMail, Facebook etc. naively.

<comment><USER11> This is only true if your correspondents are all using the same service. If you use gmail then google knows the entirety of your email network. If you host your own mail then google only knows your links to your correspondents who use gmail, but not your links to those using hotmail, facebook, etc. (unless that info is revealed to google by putting multiple recipients in the to or cc entries in the message.)</comment></comment></comment>


Norden Bombsight Principles #1 (1940s) [video] - <AUTHOR> https://www.youtube.com/watch?v=rAYRv8T5jEg <comment><AUTHOR> The Norden Bombsight was an early analog computer, made of around 2000 parts including gyroscopes, and designed to precisely drop bombs from a moving aeroplane. The bombsight was regarded as such a strategic advantage that all efforts were taken to keep it secret - such as embedding an incendiary charge inside the sight which would destroy it in case a plane was shot down.</comment>