AWS CEO Jassy follows Apple in calling for retraction of Chinese spy chip story - <AUTHOR> https://www.cnbc.com/2018/10/22/aws-ceo-jassy-follows-apple-calls-for-spy-chip-story-retraction.html <comment><USER2> There should be hundreds of thousands or millions of these hacked motherboards, and nobody has found a single one despite hardware geeks worldwide searching like it was Willy Wonka's final golden ticket. This story was bogus, it most likely came from a ton of rumors that got conflated, hence why they had to go with anonymous sources as opposed to any physical evidence. I'd be surprised if Bloomberg has any credibility in tech journalism by the end of the year, and a good chance they may end up stuck in a courtroom trying to defend the decision to run this piece (on the front page, no less) for a long, long time.

<comment><USER3> "There should be hundreds of thousands or millions of these hacked motherboards"

No, the boards would be selectively hacked.

And we know it happens because 'we' do it as well.

Surely there is evidence floating around but it's also unlikely that companies would want to admit the breach.

I kind of believe Apple and Amazon though, there's too much risk if they were to be caught lying.

This is a weird one ...

<comment><USER4> You just need ONE board to be able to prove it. Surely Bloomberg or their sources can get their hand on a single piece?

<comment><USER5> So if a newspaper wanted evidence that your company fucked up you would go and dismantle company property to discredit your employer knowing that it's likely to damage them and ruin you.

<comment><USER6> If you want to blow a whistle, yes. If not dismantle, at least photograph the object. If your employer retaliates, you can make good money in speaker fees retelling the story, or get a job at a company that wants to be known for good hardware security.

<comment><USER7> Getting a job is not necessarily a reason to jeopardize a whole career in the intelligence community. People in public service sometimes have feelings about serving their country.

</comment></comment></comment></comment></comment></comment><comment><USER8> (disclaimer: I worked at AWS from 2008 to 2014 as Technology Evangelist, and know Andy Jassy personally)

I know nothing specific about the issue per se, but I am convinced that Andy Jassy is speaking the truth here, for two reasons:

1) I've never seen a company as obsessed with security as AWS, and/or with such a big budget for security.

2) There's so many actors/employees involved in the audits, security, etc, that convincing some of them to "hide" a fact like this would be just too risky for a company that big. If that were really the case, I would rather work on a contingency plan, assuming that sooner or later the "leak" would come out.

There is a tiny chance that something bad happened, and that Amazon's magic PR twist managed to still provide a truthful statement (Steve Schmidt) while hiding that. "A chance", because of the various back and forth business between AWS and Chinese companies. "Tiny", because other scenarios are much more probable and plausible.

This looks like a very poor example of journalism, on Bloomberg's side.

On a different note, I still believe that weird/illegal stuff keeps going on between companies and governments worldwide, for the simple reason that these things keep coming up when there's a new leak, or when secrecy on certain classified documents gets lifted or expires.

<comment><USER9> If we reverse the roles, we notice how little information you actually provide except your own opinions.

<comment> dis-sys expressing yourself on an online forum is vastly different from publishing that bloomberg article with those very specific accusations.

also want to know who are "we" here? please stop representing other people without their explicit consent.

</comment></comment></comment><comment><USER10> Gruber doesn't get posted on HN much for some reason but he found a great tidbit on this: The reporters were flippantly dismissive of the (strong and repeated) company denials.[1]

Jordan Robertson was on TV saying companies have no "advantage" in "confirming" his reporting because "no consumer data [was] stolen." He seems to take very casually the distinction between "not disclosing" something and outright lying and engaging in an industry-wide conspiracy about it. He later tried to walk back that line but it's an interesting window into their mindset. It doesn't strike me as particularly strong journalistic reasoning.

[1] [https://daringfireball.net/linked/2018/10/22/jassy- bloomberg...](https://daringfireball.net/linked/2018/10/22/jassy-bloomberg- should-retract)

</comment><comment><USER11> The lack of confirming evidence is a strong sign the Bloomberg reporters were played. It's interesting to wonder who might have done that though -- US businesses who might gain? Those from within the administration?

Regardless of the truthfulness of the report, the damage is done and the hack story fits in well for the protectionist trajectory the US is taking.

<comment><USER12> It's certainly not the case that the US government has been above disinformation campaigns aimed at its own citizens even in the recent [https://www.wired.co.uk/article/mirage- men](https://www.wired.co.uk/article/mirage-men) [https://www.dailygrail.com/2013/06/a-fractured-hall-of- mirro...](https://www.dailygrail.com/2013/06/a-fractured-hall-of-mirrors/) or very recent [https://www.nytimes.com/2017/12/16/us/politics/pentagon- prog...](https://www.nytimes.com/2017/12/16/us/politics/pentagon-program-ufo- harry-reid.html) past. Though of course there would be much more political risk in lying to Bloomberg News than in using up and throwing away an old ufologist loser like Paul Bennewitz. (Still, it's even a little suprising how, in a country which avows military patriotism as strongly as the USA, the USAF can contribute to the destruction of a patriotic WWII veteran, then publicly gloat about it afterwards, and absolutely no-one gives two shits.)

<comment><USER13> What evidence do you have that AATIP was a disinformation campaign? The UFO story was extremely weird, but I've seen no evidence that the Pentagon fabricated the footage, or somehow coerced Fravor into lying on primetime TV.

Moreover, what would the Pentagon gain by running a UFO psy-op?

<comment><USER14> _> Moreover, what would the Pentagon gain by running a UFO psy-op?_

I've always wondered whether the magnitude of UFO sighting reports make it more difficult to glean intelligence about US aircraft/reconnaissance research. If, for example, Area 51 was responsible for cutting edge stealth aircraft research, it would be much more difficult to spy on the program through the civilian population if real sightings are indistinguishable from the flood of alien UFO sightings.

<comment><USER13> I've read that during the Project Blue Book era, the CIA was worried the Soviets might fuel rumors of UFOs, so that civilian observations of Soviet aircraft would get chalked up to aliens by a gullible public, and reports of unusual activity would be discredited.

I don't have the citation on hand but the declassified PBB files are available on the Internet Archive.

</comment></comment></comment></comment></comment><comment><USER15> An easy way Bloomberg could support their story: allow one or more of their "senior insider" sources at Apple/Amazon to speak with another outlet (AP, NYT, whoever) who agrees to maintain their anonymity.

<comment><USER2> One of the interviewees did speak (though he's not apple or amazon), and said that Bloomberg completely misrepresented what he said to support this theory, which he totally disagrees with: [https://9to5mac.com/2018/10/09/bloomberg/](https://9to5mac.com/2018/10/09/bloomberg/)

<comment><USER16> The article you linked states, Bloomberg says:

> Joe FitzPatrick was not one of these 17 individual primary sources that > included company insiders and government officials,

<comment><USER2> Oh, he was one of the named sources. Good catch, though that doesn't change the point.

<comment><USER17> The _entire_ story is an elaboration of a hypothetical example Fitzpatrick gave in consultation. That the final article is an exact match is seriously problematic.

</comment></comment></comment></comment></comment><comment><USER18> 2016 report by ARS Technica: [https://arstechnica.com/information- technology/2016/03/repor...](https://arstechnica.com/information- technology/2016/03/report-apple-designing-its-own-servers-to-avoid-snooping/)

2017 followup by ARS Technica: [https://arstechnica.com/information- technology/2017/02/apple...](https://arstechnica.com/information- technology/2017/02/apple-axed-supermicro-servers-from-datacenters-because-of- bad-firmware-update/)

So the story is 2 years old from a reporting standpoint.

<comment><USER19> Dodgy firmware is nothing new, it's just compromised code after all.

<comment><USER20> According to Bloomberg, that's how everything started:

> Apple made its discovery of suspicious chips inside Supermicro servers > around May 2015, after detecting odd network activity and firmware problems, > according to a person familiar with the timeline. Two of the senior Apple > insiders say the company reported the incident to the FBI but kept details > about what it had detected tightly held, even internally. Government > investigators were still chasing clues on their own when Amazon made its > discovery and gave them access to sabotaged hardware, according to one U.S. > official. This created an invaluable opportunity for intelligence agencies > and the FBI—by then running a full investigation led by its cyber- and > counterintelligence teams—to see what the chips looked like and how they > worked.

If this was true, the public denials wouldn't surprise me at all.

<comment><USER19> And if that's how the Bloomberg article had ended, with well known and previously reported firmware issues, we wouldn't be having this discussion.

</comment></comment></comment></comment><comment><USER21> If Bloomberg ends up retracting the story, then the new question, for me, is how did this happen? Was it simply Bloomberg trying to get views? Or is it more interesting, like did their "sources" intentionally give them a fake story in order to hurt their credibility? Or was it to cast doubt on the anti- China stories in general?

<comment><USER22> It should be pointed out that Bloomberg authors get bonuses if they write stories that move the market:

[https://www.businessinsider.com/bloomberg-reporters- compensa...](https://www.businessinsider.com/bloomberg-reporters- compensation-2013-12)

Not saying that was necessarily a motivation here, but it's worth pointing out.

<comment><USER23> Keep parroting this if you want, but that ended in 2014.

</comment></comment></comment><comment><USER24> The denials seem convincing. And yet the story seems very much plausible. US NSA does these kinds of attacks, why not China?

> They offered no proof, story kept changing, and showed no interest in our > answers unless we could validate their theories

If that's really the case then it seems likely that their source may have indeed deceived them. But don't they have multiple sources?

> The article also claims ... we conducted a network-wide audit of SuperMicro > motherboards and discovered the malicious chips in a Beijing data center.

Bloomberg's source for this claim must be distinct from the Israeli security researcher, right?

Perhaps, if this was a Russian HUMINT attack, it's another glorious success for GRU.

<comment><USER25> The NSA has never done something on this scale. With sec researchers looking at _everything_ right now it would have been uncovered by now. The major point in this story wasn't a hardware hack, it was a hardware hack on a MASSIVE scale, a scale that would have to be treated as an act of war against the _rest of the world_.

If this article were true it would have been the first public volley in WWIII.

<comment><USER26> The number of implants doesn't need to be that great. If you are already tapped into Supermicro's supply chain and ordering system, then you can already figure out when a bulk of servers passing through manufacturing are going out to a certain customer. Bribe someone or have an agent on the floor slip in the implant during assembly. Maybe the gerber files for the boards already have the necessary pads built-in for debug, maybe someone is swapping in modified gerbers. Maybe the implant is installed totally after hours when the boards are already built or when they are on their way to the final assembly facility.

</comment></comment></comment><comment><USER27> Any reason for these calls for retraction?

It's not like there aren't false stories about what happens at Apple or Amazon regularly, not that they're usually about hacking but the public calls for retraction seem somewhat as unique as the story.

<comment><USER28> Agreed. The pointed denials make the whole thing even weirder.

</comment></comment><comment><USER29> It's really starting to smell like Bloomberg got played hard here. To preserve their journalistic integrity they either need to produce some supporting evidence real fast or admit they screwed up and retract the story.

<comment><USER30> Smells more and more like something 4chan would do.

</comment></comment><comment><USER31> I said it recently in different words and I'll say it again. There is no good ending for Bloomberg in this story, or at least for the reporters on the story and the editor who let it run. The longer it digs its heels in adamantly and doesn't retract this story, the worse it's going to get. Its deep pockets can handle a huge scandal and embarrassment for a while, but it'll face the ignominy of being ignored by sources in many circles if it doesn't act quickly (one of the ways, perhaps, would be to reveal more information that can be verified by third parties). It's as sticky a situation as it gets, and it will define/decimate Bloomberg for the future.

</comment><comment><USER32> What's more plausible in this scenario: One or two journalists run a fake story, possibly for financial gain or simply notoriety, or that hundreds and even thousands of engineers and managers across multiple tech companies are all complicit in the most elaborate and coordinated corporate conspiracy in history, all just to hide the fact that they were breached...

<comment><USER28> It's possible that the hack wasn't that big (targeted to only certain boards) and that the higher-ups at the companies don't know the details

</comment></comment><comment><USER33> I'm curious how the internal meeting (at the newspaper) goes, when they have no actual proof, such as an actual compromised device. How could you possibly publish such a huge/important story without that smoking gun?

We live in too much of a scientific/fact driven period of time to allow this to be taken seriously in my opinion.

</comment><comment><USER34> With the "trade war" going on I wouldn't be surprised if this was intentionally put out in order to reduce the us dependency on china.

<comment><USER35> Overpriced corrupt vendors are likely hurting to open compute designs and hardware.

</comment></comment><comment><USER36> Why was Google not affected by these Supermicro motherboards?

<comment><USER37> From my scouring some time ago on Ebay Google seems to use board designs modified and produces to their specs from some Taywan nonames. So while they also can potentially be similarly attacked, it wouldn't be the same attack.

Wrt. the subj of the Bloomberg story - back in 90ies Russian FSB would comb through the internals of every PCs they bought for their use. That though was before Intel ME :)

</comment></comment><comment><USER38> This story probably came from someone in the national security establishment who has zero understanding of the underlying technology but has a vested interest in the red scare..

</comment><comment><USER39> What's up with calling these division leads as "CEO"? Do they only answer to the board elected by shareholders?

</comment><comment><USER40> Sounds like they are running scared? Could this be a cover up do you think?

</comment><comment><USER41> Surely at least a few of these boards should be floating around, can't Bloomberg or others dig up a few physical examples? Unlike software 0 days or other more ephemeral issues this should be hard to conceal and easy to reproduce.

</comment><comment><USER42> It's not fake news unless you hurt me!

</comment><comment><USER43> [removed]

<comment><USER2> If that's the only question then the answer for every major company is "guilty". I don't think doing business in china means that Bloomberg gets to make up a bunch of BS from mysterious anonymous sources without a single piece of physical evidence, wiping out billions in market value, and just call it a day and we're all supposed to believe it because they use the word "China". I think we can probably hold them, and ourselves, to a higher standard of journalism. Though, clearly there is a huge market for China-hating technopanic, no matter how little evidence or credibility there may be, since some people will literally believe anything if they think it's done in China.

<comment><USER44> It isn't really plausible that Bloomberg made up the story. They had to have a high degree of confidence to publish it. The question we all need to be asking is why they had that high degree of confidence. Where their information came from and whether or not those sources had ulterior motives to lead Bloomberg astray.

I have to imagine Bloomberg is also trying to find out why their story has not matched statements by the companies alleged to be involved so starkly. There is a story here, but what that story actually is is definitely in question.

<comment><USER45> Yeah, my hunch (like yours) is that everyone involved--Bloomberg, Apple, AWS-- believes, in good faith, in what they have stated, and have collected more than enough evidence to back those statements. Since there's a contradiction, the truth is probably fairly weird, if it's enough to provide so much conflicting evidence both ways.

The least weird conclusion is that Bloomberg connected too many dots the wrong way around and are embarrassed to admit it.

</comment></comment></comment></comment><comment><USER46> are they aware statements like this confirm it?

If it were false the case would fall under libel and slander.

Someone is obfuscating truths here

<comment><USER47> Libel and defamation lawsuits are tricky because one would need to prove that Bloomberg ran the story knowing it was false or ran the story with "reckless disregard" for the factual accuracy of the reporting _and_ prove that the article resulted in damage to the plaintiff.

Many dubious articles go unchallenged because it's often not worth pursuing legal action.

<comment><USER48> It's not like these companies don't have the money or legal resources to do it though.

</comment></comment></comment><comment><USER49> Why did these demands for retraction take so long?

<comment><USER2> They quadruple-checked all their audits to make sure they were actually accurate in saying "nothing here".

<comment><USER50> Precisely. Worst thing would be to realize later you overlooked something and have to issue a correction.

And a story with this many moving pieces, you've got a lot of ground to cover. It's so very hard to prove the absence of something.

</comment></comment></comment><comment><USER51> That's well and good and all...but it's in Amazon and Apple's best interest to deny everything.

<comment><USER52> It is? They're both public companies. If they get caught having strongly denied something that's true, that's worse than no comment, and the inevitable stock market motion and shareholder lawsuits that will result.

</comment></comment><comment><USER53> As a press outlet they have a pretty solid defense in the first amendment

<comment><USER54> They pay their journalists bonuses if they move the market. That gives some pretty perverse incentives to the journalists.

<comment><USER53> What's perverse about it? Bloomberg decided that the market is a good way to measure impact of their stories. They're business reporters, so that makes sense. The incentive is not directional; it doesn't rely on reporters causing a stock to lose value or gain it.

<comment><USER55> > The incentive is not directional

The magnitude matters. Meaning journalists have an incentive to stretch the truth in either direction, as long as it'll get a reaction. A journalist now has to weigh this monetary incentive against their other incentives for being non-hyperbolic, truthful journalists.

<comment><USER53> The business insider article linked above makes it sound like a relatively nuanced measure. If the article makes a big splash but then gets wiped away by follow-up reporting, it doesn't sound like it gets rewarded.

Think about articles that don't move the market: did they contain novel, important information? If so, why didn't the market move?

It seems like this incentive encourages prioritizing stories which are unreported and meaningful.

</comment></comment></comment></comment></comment><comment><USER56> I really have little doubt that the Chinese are integrating their spy chips into computer hardware going to the big four or even the pentagon. It's probably how they stole the designs to the f-35[you know that plane that costs over a trillion dollars to develop]. It would catastrophic if apple knew or even acknowledges the possibility of the Chinese having a backdoor into their servers and would result in massive shift in policy[+profit].

The NSA has been known to intercept electronics in shipping and putting in their own specialized pcb board replacements with microphones, cameras, etc. and are _very_ hard to detect. Hell the Russian even went back to typewriters for security purposes[0]. It would be foolish to think that the Chinese/Russians aren't doing the same thing to us.

[0]:[https://www.telegraph.co.uk/news/worldnews/europe/russia/101...](https://www.telegraph.co.uk/news/worldnews/europe/russia/10173645/Kremlin- returns-to-typewriters-to-avoid-computer-leaks.html)

<comment><USER57> Saying "The Chinese are probably doing something bad" is very different from the very specific accusations that were made; "The Chinese are doing the same thing to us" is not a news story - what was reported by Bloomberg _was_ a news story.

My point is that hand wavy "they have to be spying somewhere" is in no way a defense for the Bloomberg story. My reason why I'm very skeptical of the story is that I think it would be possible that SOMEONE would have physical evidence of it (given that it was a hardware hack) that they could show. So far Bloomberg hasn't really shown anything to back up their story.

<comment><USER2> "Well it sounds like it could be real, so it's probably true" \- I'm not sure why anyone thinks this is an acceptable counter-argument.</comment></comment></comment>


CVE-2019-14287: Sudo Bug Allows Restricted Users to Run Commands as Root - <AUTHOR> https://sensorstechforum.com/cve-2019-14287-sudo-bug/ <comment><USER2> This is technically an interesting bug, but the implications are very minor. The only situation where this can be exploited is when you allow a user to execute something as any other users except root. This seems pretty obscure and probably affects only an extremely small number of configurations.

Pretty much all the headlines I saw on this were overstating or stretching the impact.

<comment><USER3> No question about the headlines overstating.

But I don't think this is a rare situation. For example you can allow a bunch of users to restart and change a buildbot infrastructure (which runs as its own user, not root).

<comment><USER4> But you are giving them access to that specific build user, not "ALL" followed by "!root".

</comment></comment></comment><comment><USER5> Yesterday's discussion: [https://news.ycombinator.com/item?id=21252285](https://news.ycombinator.com/item?id=21252285)

</comment><comment><USER6> Does anybody actually have sudo access on a system that they don't also have 100% control over?

I feel like linux as a true multi-user system, especially to the level of having sudo access, is such a minority use case that I would never actually trust it in production.

<comment><USER7> In high performance computing, the supercomputing cluster is usually a shared Linux environment. Each user gets a home directory and groups are used for projects. As an intern working on one, they gave me limited sudo access to run a few commands but not everything (stuff like reading logs was fine but not able to power off the cluster).</comment></comment>


Why doesn't mathematics collapse, though humans often make mistakes in proofs? - <AUTHOR> https://mathoverflow.net/questions/338607/why-doesnt-mathematics-collapse-down-even-though-humans-quite-often-make-mista <comment><USER2> "Once in a while, I like to indulge in an informative anecdote concerning the genesis of the proof. The criterion was found by the end of 1985; then I remained more than six months making circles around the « splitting tensor ». One nice day of August 1986, I woke up in a camp in Siena and I had got the proof: I therefore sat down and wrote a manuscript of 10 pages. One month later, while recopying this with my typewriter, I discovered that one of my lemmas about imperialism was wrong: no importance, I made another one! This illustrates the fact, neglected by the formalist ideology, that a proof is not the mere putting side by side of logical rules, it is a global perception: since I had found the concept of empire, I had my theorem and the faulty lemma was hardly more than a misprint."

\- Jean-Yves Girard, The Blind Spot

<comment><USER3> Complementing this situation, there are also cases where a proof hinges on a critical corollary or theorem where "no importance, I made another one!" did not or does not come as easily.

One recent example is Corollary 3.12 in Mochizuki's series of papers on Inter- universal Teichmüller Theory. This single corollary is the main topic of "Why abc is is still a conjecture" by Peter Scholze and Jakob Stix:

[http://www.kurims.kyoto-u.ac.jp/~motizuki/SS2018-08.pdf](http://www.kurims.kyoto-u.ac.jp/~motizuki/SS2018-08.pdf)

Quoting from the paper:

 _" We are going to explain where, in our opinion, the suggested proof has a problem, a problem so severe that in our opinion small modifications will not rescue the proof strategy."_

An argument can be made that hence, this is no proof at all, and indeed that is the conclusion of the paper. However, mistakes in other suggested proofs were also found in the past, and they could sometimes be salvaged with significant new insights and additional work. An example for this is Andrew Wiles's proof of Fermat's Last Theorem. Quoting from [https://en.wikipedia.org/wiki/Wiles%27s_proof_of_Fermat%27s_...](https://en.wikipedia.org/wiki/Wiles%27s_proof_of_Fermat%27s_Last_Theorem):

 _Wiles states that on the morning of 19 September 1994, he was on the verge of giving up and was almost resigned to accepting that he had failed, and to publishing his work so that others could build on it and find the error. He states that he was having a final look to try and understand the fundamental reasons why his approach could not be made to work, when he had a sudden insight that ..._

<comment><USER4> Mochizuki's paper seems like a debatable example. Many mathematicians have been baffled by the proof or ended up feeling that it was not that promising, even prior to attempting to do a detailed analysis. If it's unrecoverable, then the community will look good for its hesitation. [https://news.ycombinator.com/item?id=15971802](https://news.ycombinator.com/item?id=15971802)

<comment><USER3> Take for instance Wu-Yi Hsiang's suggested proof of the Kepler conjecture as a less controversial example.

Quoting from [https://en.wikipedia.org/wiki/Kepler_conjecture](https://en.wikipedia.org/wiki/Kepler_conjecture):

 _" The proof was praised by Encyclopædia Britannica and Science and Hsiang was also honored at joint meetings of AMS-MAA."_

Which is followed, after a few sentences, by:

 _" The current consensus is that Hsiang's proof is incomplete."_

<comment><USER5> Or Kempe's (mistaken) proof of the 4 color theorem.

</comment></comment></comment></comment></comment><comment><USER6> Collapses are rare indeed, but they do happen. _Cf_. the collapse of the Italian School of Algebraic Geometry [1], the cleanup of which took all the efforts of Grothendieck _et al_.

[1] [https://en.wikipedia.org/wiki/Italian_school_of_algebraic_ge...](https://en.wikipedia.org/wiki/Italian_school_of_algebraic_geometry#Collapse_of_the_school)

<comment><USER7> That's pretty incredible, thanks for sharing. Hard to believe decades of mathematical research collapsed on itself.

</comment></comment><comment><USER8> If builders of a huge castle place some stones incorrectly, does it collapse completely?

No. Such errors may be discovered soon and taken down, or stand for decades, sometimes with lots of stuff built on top of it, and sometime parts will collapse, but the overall structure of the castle is sound, and, sooner or later, errors will be corrected.

And of course, sometimes, somebody decides to start building an entire new wing to the castle using new rules, as, for example, happened when non- Euclidean geometry was discovered/invented.

<comment><USER9> On the analogy of castles, I asked a professor whether Godel's Incompleteness theorems affects their work. She told me Mathematics is this great castle, where in one quadrant you have the number theorist, in another the topologists. Every decade or century, the logicians would come running up from the basement with results confronting the foundations of math, but everyone else continued with their routine

<comment><USER10> AFAICT mathematical logic has always felt like a curious side show in the greater math community. If you were to ask professional mathematicians to list off all the axioms of ZFC they'd probably shrug if they didn't get all of them. They probably wouldn't know about the more exotic parts of set theory such as large cardinals nor would they would probably know too much about alternate foundations of mathematics. They might not be familiar at all with the specifics of model theory.

The logical foundations of mathematics have always had a much smaller impact on the day to day lives of mathematicians than their foundational nature might suggest.

<comment><USER11> That's because formal logic is a (relatively) recent attempt to formalize the intuitions behind the math that people were already doing. Doing mathematics doesn't _really_ depend on foundational logic in the same way that, e.g., a web app depends on transistor physics.

As somebody once said, if we ever found a contradiction in the ZFC axioms, we wouldn't throw out math, we'd just throw out ZFC.

<comment><USER12> > Doing mathematics doesn't really depend on foundational logic in the same > way that, e.g., a web app depends on transistor physics.

Web apps don't depend on transistor physics at all, though. An important consequence of Turing universality is that computer science is not a subfield of electrical engineering.

Also, mathematics underwent very dramatic transformations during the late 1800s and early 1900s alongside the early development of formal logic and set theory. To say that logicians were merely "formalizing the intuitions behind the math that people were already doing" strikes me as misguided at best. The mathematics that rose to prominence in that era was very different from what preceded it, often controversially so.

</comment></comment></comment></comment></comment><comment><USER13> An idea related to this helped me get a grasp on writing proofs when I was first struggling to teach myself mathematics.

The idea was roughly:

A particular formalized proof (or lemma) is one of many ways of expressing/representing a more general concept that grounds some mathematical idea. It seems to mirror the way you could have the general concept of "having gone to the store and purchased bananas" in your head but express it many different ways through natural language.

If humans were doing mathematics by thinking purely in terms of the theorem space of some particular formal system, then 'collapses' should be expected after minor errors: if you take one wrong turn, your error should be compounded in any further progress.

But that does not appear to be how we do mathematics. Instead we're operating in a more general space of concepts, and we do _not_ do math by proceeding linearly in our thoughts from the beginning of a proof to the final conclusion --we assemble the conception piecemeal until we get some feel for the sufficient overall integrity/coherence of a general conception, and then secure it by building up a kind of formal carapace around it. But if part of the proof/carapace is wrong, it's like a malformed section of armor that needs to be replaced: the whole structure isn't going to collapse because of it (not that that _couldn 't_ happen).

Thinking about things that way gave me a better view (I think) on how to use and think about formalizations when doing mathematics.

</comment><comment><USER14> Many answers which I think miss the big question.

Mathematics doesn't collapse like a house of cards because the more "important" a proof is to the foundations of math, the more frequently it is tested. A counterexample to a proof is an easy way to find errors up the chain.

In the other direction is that many things that might be considered "errors" in the foundations could be looked at more like choices. Others mentioned Euclidian vs non-Euclidian geometry. There was a sort of error of the idea that Euclidian geometry was the only geometry which was _fixed_ not by tearing it down but creating new geometries.

</comment><comment><USER15> I'd venture that the reason that mathematics doesn't risk imploding is because ultimately it can be treated as a fairly empirical body of knowledge, and maps accurately to the world as we observe it (or rather, the implications of pure mathematics, when applied by the sciences, give results that are not ad odds with reality as we observe it to be).

</comment><comment> 1e-9 I think it wise to be skeptical of any new result coming from a complicated proof until it has been proven multiple ways by multiple people. If multiple approaches are not easily attained, then passing the test of multiple counterexample attempts can at least provide some degree of confidence. If something new is significant, it tends to attract that kind of scrutiny pretty quickly. I think that is the saving grace of the mathematics community.

</comment><comment><USER16> I think that mathematicians should strive to use formal language proofs verified by computer. It'll allow to avoid situations when it's unclear whether this proof is correct or not and it'll allow people not to waste time on checking whether that proof is correct.

<comment><USER17> I have done a little with [http://us.metamath.org/](http://us.metamath.org/) and I am sure within 10 years every professional mathematician will use formal proofs.

The two prerequisites are 1) making a fluid and intuitive interface for inputting proofs which can also display human readable proofs for any theorem known and 2) creating a database of all known mathematical proofs into which new results can be inserted.

Both tasks are ~50% complete. Metamath, for example, has all of mathematics formalised up to a basic undergraduate level. It has some reasonable editing software, but not close to good enough for mass adoption. There are also plenty of other systems being developed.

The time will come though relatively soon.

<comment><USER18> > I am sure within 10 years every professional mathematician will use formal > proofs.

I'll take that bet. 1:1 odds, up to $50? Shall we say, every mathematician employed at an ivy league university math department (postdoc level or above) has published at least one paper which employs proof checking for at least some claim? (provided that they have published at all.) So I win if I can find at least one professor or postdoc employed at an ivy league university math department on August 18, 2029, who has published at least one mathematics paper, and who has not published any mathematics paper which contains any formal proof.

That's a much weaker claim than yours, so it ought to be pretty generous to you.

<comment><USER19> I just wanted to note how precise of a bet this is. I will be stealing the exact definition of conditions and contexts to which the bet applies, to future bets of my own.

</comment></comment></comment></comment><comment><USER20> Why would it even mean for mathematics to collapse? It's obvious that if a branch is based on rules that don't make sense, at some point that branch will break. But it only breaks to the root node, which is fine. But why would the whole edifice collapse?

</comment><comment><USER21> Ted Chiang's short story "Division by Zero", about a mathematician who discovers the foundations of mathematics are inconsistent, would appear to be relevant to this discussion.

<comment><USER22> Could you share more or summarize?

<comment><USER23> Here's a brief synopsis: [http://kasmana.people.cofc.edu/MATHFICT/mfview.php?callnumbe...](http://kasmana.people.cofc.edu/MATHFICT/mfview.php?callnumber=mf194)

</comment></comment></comment><comment><USER24> Pretty funny to see Simpson's name showing up here. I have kept two souvenirs from my academic life: the original manuscript of my thesis and Simpson's very eloquent and overwhelmingly positive review of it.

Regarding the topic, I'd say that mathematics, as a whole, is a set of intuitions and ideas, rather than strict proofs. I've spent a fair amount of time working my way through some of Kontsevich's ideas and attended many of his talks -- he rarely (if ever) gives any proofs, my educated guess is that he proposes some extremely profound ideas and his collaborators grind through the details (not always). And it still works just fine.

I remember Kenji Fukaya saying once, talking about a PDE-heavy theorem: "We are trying to keep the details of the proof under 500 pages and it's not sa easy". The main issue here is that people who don't do professional, academic research in mathematics are unaware of the complexity of modern maths. It has evolved immensely during last 50 years, the theories are just layers and layers of foundational work one has to assimilate before getting any work done. Rigorous verification takes years and no one in the academia is being offered a job for proof-reading of existing papers.

One should also remember that referees of the papers are not being paid, it's considered "work for the community" and it's hard to blame them for not reading the papers in detail.

Mathematics are anti-fragile.

</comment><comment><USER25> Isn't this like asking why society doesn't collapse, when the software that drives it is filled with bugs?

 _My impression was: any result in modern mathematics critically depends on another result, and that result depends on some other result..._

This is like how most large software systems depend on various 3rd party libraries.

I guess the answer for both questions is that the things we build, whether they be mathematics or software, work well enough most of the time that you don't notice the problems unless you're paying attention.

</comment><comment><USER26> >senior undergraduate student in mathematics Yikes. The student is only now getting around to first year ideas that everything they know might be a sham. I mean... come on.

I mean, what does the student think will happen? We'll all realize that pi=4? Planes will fall out of the sky because physics finally caught up with a mistake in a proof?

</comment><comment><USER27> Mathematical physics and engineering holds up to empirical scrutiny.

<comment><USER28> Exactly this. Mathematics provides an imperfect model that needs to be adjusted for engineering problems in the messy, real world.

<comment><USER29> Maybe true about physics (as physics does strive to provide approximate models of reality), but mathematics is abstract and for most mathematicians any application to reality is coincidental. You might enjoy reading "The unreasonable effectiveness of mathematics" (it is many decades old, but recently a lot of CS essays copy the style and title).

<comment><USER30> "The unreasonable effectiveness of mathematics" just always struck me as similar to commenting on how noses are made to fit glasses.

</comment></comment></comment></comment><comment><USER31> The more boring answer correctness is testable. If I present a proof that two equations are equal, you don't have to trust me. You can try some values and see if they work, look for a contradiction, try to produce your own proof, or any other test you can think up.

</comment><comment><USER32> Think about Curry Howard isomorphism which says programs are proofs and data- types are theorems.

A lemma is then like sub-routine.

If there is something wrong in the sub-routine it can often be fixed without requiring any changes to the callers of the sub-routine. It might be the case that the subroutine can never produce a value needed by its callers without changing the types of arguments fed to it, and in such a case it is not enough to fix the subroutine.

But in many cases just the lemma-subroutine needs to be corrected, and the rest of the program, rest of the proof can be used as is.

[https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspon...](https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence)

<comment><USER33> The vast majority of mathematics is classical, not intuitionistic, just so you know.

</comment></comment><comment><USER34> There is no proof in science and we observe it doesn't suffer from wholesale collapse.

Things being proved in mathematics are unlikely to be wildly wrong even without proof. Fermat's theorem being an example of one that took a very long time to be proved and basically nothing changed when it was. We were already convinced it was true by brute force failure to find a counter example. This lack of proof but search for counter-example is basically the scientific method. Is A equivalent to B? Prove it? Or write a for-loop and test it for values you care about. If you think you've proved it you probably write the for loop anyway (where such a thing is feasible).

So do we actually /need/ proof in math at all or is it just good fun and properly satisfying for mathematicians? Perhaps these are two extremes and case-by-case we could plot them somehwere between the two. Some right up hard against one side or the other.

So is P=NP? There is no proof. You probably aren't going out on a massive limb to have a view on the matter without it.

</comment><comment><USER9> The simpler and more elegant the proof, the less likely we are to commit an error

</comment><comment><USER35> It probably helps that quite a lot interesting mathematics is the result of figuring out exactly _why_ something doesn't work.

</comment><comment><USER36> Mathematics is convex to errors

<comment><USER37> Supposing that the definition of convexity that you're referring to is that of, for a set C with x_1 and x_2 being elements of C and for any scalar b between zero and one inclusively,

[b * x_1 + (1 - b) * x_2] always being a member of C,

I presume that you mean that errors, namely those kind of errors that are the subject of this thread's discussion, in mathematics will always symbolically be elements of some solution set of a finite number of linear equalities and inequalities (or the intersection of a finite number of halfspaces and hyperplanes).

<comment><USER38> It is informal and means that mistakes hurt less than non-mistakes help.

A hypertechnical article that gives the gist:

[https://www.edge.org/conversation/nassim_nicholas_taleb- unde...](https://www.edge.org/conversation/nassim_nicholas_taleb- understanding-is-a-poor-substitute-for-convexity-antifragility)

</comment></comment></comment><comment><USER39> tldr; humans change their theorems/lemmas to make them fit their initial model, i.e. add caveats.

</comment><comment><USER40> Platonism ftw!

</comment><comment><USER41> Or does it...? Case in point, the fifth axiom of geometry, attributed to Euclid, that through a point there is exactly one line parallel to a given line has been shown to be unprovable, and Lobachevski and Rieman have built alternative geometric theories assuming that axiom wrong.

I find it hard to believe that Math is that different from physics or other sciences in its robustness.

Some advantages that math has had over other sciences is low resource consumption (pen and paper), easier reproducibility(thinking), and it has gotten a long head start of 2-3 thousand years.

<comment><USER42> Axioms shouldn't be provable (other than from themselves) - if the fifth axiom of geometry had turned out to be provable from something else, then it would be have just been renamed a theorem instead of an axiom.

<comment><USER43> That's the wrong way to think about it, I think.

It's more correct to think of axioms as being preconditions.

We say, "Here is what happens if these things are true", and then specify what happens, but that doesn't deprive us from independently checking whether those conditions are true. Just because something has been proven does not stop it from being an axiom. It's contextural.

</comment></comment></comment><comment><USER44> I have never understood why proofs are always required. Usually when you have an unproven theorem and it works often enough, to me it's good enough for most of what you're doing, for example in applied math. Of course if you find places where an unproven theorem doesn't work, it becomes interesting to why it doesn't work, and it's usually a big discovery, but it doesn't really disprove a theorem, it just helps to refine it.

I remember that in school teachers were often insisting about giving a proof to something, but to me it often made enough sense and it was often right, and it was often frustrating to have teachers tell you "no". It felt like a burden of proof.

<comment><USER45> Well, broadly speaking, pure mathematics _is_ picking some axioms, and then proving rigorous results based on them. If that doesn't sound like a fun game to you, you don't need to play it or watch it.

<comment><USER44> Not saying it's not fun, but to me proofs don't seem to help me understanding mathematics.

Not saying proofs are not important, but it seems that proving a theorem is important at a higher levels of mathematics, not in high school or university.</comment></comment></comment>


Show HN: Doomguy as a Service - <AUTHOR> https://doomguy.herokuapp.com

<comment><USER2> Are we really so desperate to stick with buzzwords and "hot tech" that we wind up creating Heroku-powered Ruby apps with Bootstrap UI widget-filled pages to serve up a set of 5 static images over HTTP, rather than just, say, uploading them to imgur?

<comment><USER3> Whilst this is a post of derision, I do think people only know the highest level abstraction mankind can accomplish these days. It's embarrassing really. There is elegance in simplicity.

Please continue to take the piss out of it :)

I actually knocked up a single new static error page for our main web application a few weeks ago in 620 bytes including inline css (quite big if you ask me). It had no dependencies. My coworkers were actually astounded that it was so small!?!?!

Go figure!

<comment><USER4> For some reason seeing a size expressed in bytes makes it seem small. Saying 620 characters sounds much more reasonable.

<comment><USER3> It was UTF8 so no guarantee about character versus byte size.

</comment></comment></comment></comment><comment><USER5> The Linux utility the creator of this couldn't find: [http://www.cs.unm.edu/~dlchao/flake/doom/](http://www.cs.unm.edu/~dlchao/flake/doom/)

</comment><comment><USER6> Don't forget there's a god mode face image too: [https://www.google.com/search?q=doom+god+mode&source=lnms&tb...](https://www.google.com/search?q=doom+god+mode&source=lnms&tbm=isch&sa=X&ei=-2pQUqrkBMbtiQKgmYHQBw&ved=0CAkQ_AUoAQ&biw=1246&bih=971&dpr=1)

I made a similar doom guy visualization long ago to monitor server health that got some laughs from coworkers. Like it was mentioned, be careful since the Doom assets are still copyright id software even if the code and shareware WADs are free.

</comment><comment><USER7> I don't understand the point of redirecting every number between 0 and 100 when there are only five gifs.

<comment><USER6> I'm guessing his intention is that you build an app which scales its metrics to values between 0-100 and then construct a URL directly to the image--that way you don't need to worry about mapping the value to the damage inflicted.

<comment><USER7> I guess, but then you have to scale to 0-100 (don't forget to round!), which doesn't seem any more convenient.

</comment></comment></comment><comment><USER8> This is cute but it needs to be obnoxious, not cute. Give me monsters coming out, the screen flashing red when you're hurting and dying etc. If this dude shows up in the middle of your dashboard attacking you you're going to notice. [http://cdn.gametop.com/download- free/doom/b2.jpg](http://cdn.gametop.com/download-free/doom/b2.jpg)

Also if the enemies, one per metric, are killed with a chainsaw when your numbers improve or stabilize that would be somewhere close to the pinnacle of awesome.

</comment><comment><USER9> I didn't know they released the WAD as public domain.

</comment><comment><USER10> I'm genuinely disappointed that IDDQD did not turn him god mode.</comment>


Android now has 68% of the global smartphone market. - <AUTHOR> http://www.businessinsider.com/android-is-crushing-apple-in-smartphone-shipments-worldwide-2012-8

<comment><AUTHOR> Another interesting stat from the linked-to source article: "China accounted for 27% of the 158 million global smart phone shipments, compared to 16% for the United States.". Within China itself, 81% of smartphones are Android.</comment>


iOS Development Tips If You're Just starting Out - <AUTHOR> http://stuartkhall.com/posts/ios-development-tips-i-would-want-if-i-was-starting-out-today <comment><USER2> As long as the beginners are drifting by, lemme say this:

Every nib you use is a boatload of code you don't have to maintain. Use nibs. Can they solve every problem? Goodness no. But they're a great way to get the basics of your views laid out. They give you an easy way to preview the behavior of your view when layout changes.

And they're very forgiving when you change your mind. Changing text alignment? One click. Want to change the balance or padding of some elements? Nudge them around with a real time preview until you're happy. Mess with different color combinations in your UI to your heart's contentment.

Doing all your view layout in code gets damn tedious when you have to compile and run each time to check your results.

Every now and then some crackpot will come along and tell you never to use nibs. Ignore them. Use nibs when they make sense for your workflow. End sermon.

<comment><USER3> In all the teams I've worked on, designers have worked out pixel positions and text alignment by the time I see the mocks. I don't find much value in realtime feedback.

Nibs are handy if you're sticking to stock UI and stock behavior. Programmatic layout takes longer to setup the boilerplate, but once it's in place, I find it about as easy to work in code as nibs. With complex designs, I find it significantly easier to work programmatically.

<comment><USER2> > In all the teams I've worked on, designers have worked out pixel positions > and text alignment by the time I see the mocks. I don't find much value in > realtime feedback.

Very few beginner iOS developers will have a design team at their beck and call.

<comment><USER4> But some of us are both ;)

<comment><USER5> And what do you think of NIBs, from the perspective of each of those two hats you are wearing?

<comment><USER4> Being fairly new to this, and doing a large amount of experimenting, I enjoy being able to quickly mockup a (sort of) working prototype, without having to type too much code. During the learning process, you just want an interface, and not much else.

I guess it comes down to workflow, and that's always a personal thing.

</comment></comment></comment></comment></comment></comment><comment><USER6> A surprisingly good list. Beyond the xib issue, which other have talked about, I would add a couple of points:

\- If developing a trivial utility app you're expecting to release quickly, target iOS version N-1. Any user who is more that one major iOS version behind won't be the type of user who will download your app (or any app really).

If developing anything more ambitious, target the latest iOS version only and take full advantage its new APIs. By the time you're ready to go mainstream (a few iterations of the app under your belt, nailed your marketing strategy, etc), there will have been at least one new major iOS version released and any time and effort you spent writing code for older iOS versions will have been wasted.

(talking from experience here :)

\- Before writing a single line of code, sort out your logging. At the very least, use a handful of macros like [0] to print the class, message name and line number when logging and to exclude debug log statements from release builds. Or check out something like CocoaLumberjack (haven't tried myself yet but writing this made me realize I need to sort out my own logging system so will give it a shot).

[0] [http://stackoverflow.com/questions/969130/how-to-print- out-t...](http://stackoverflow.com/questions/969130/how-to-print-out-the- method-name-and-line-number-and-conditionally-disable-nslog)

<comment><USER6> One last tip that bit us hard: beware of universal apps (apps designed for both iPhone and iPad).

Once you've published your app as universal, there is no way back. You can't decide in a subsequent update to revert to an iPhone-only or iPad-only app - Apple won't let you.

So if you start with an iPhone app, and then put together an iPad version of the UI just to try out and publish it as a universal app, you'll be stuck with having to provide an iPad version of your app for the rest of times. Even if you realize that the iPad version isn't worth it for your app and that nobody uses it, you won't be able to discontinue it.

So think very carefully before flicking that switch.

<comment><USER7> Interesting point.

You also won't be able to charge different prices for the iPad and iPhone versions either. Although you probably could make separate in-app purchases that get offered based on device type.

</comment></comment></comment><comment><USER8> Utilizing storyboards and xibs is one of the best way to decrease development time. Stop the coding madness!!!!

The only people I still know that avoid heavy utilization of these do not understand how to properly use them. Go learn!

<comment><USER9> I started out using XIBs, but also found myself moving a lot of my controllers away from them as soon as things got non-trivial. The biggest problem I found was weak layout support, so if you had a lot of dynamic content in a screen, it was easier to make a flexible layout in code.

I also agree that the lack of "diffability" for XIBs, despite them being XML, is a pain.

Maybe I was missing something, but my experience matches the OP.

<comment><USER10> Perhaps you're missing something. XIBs are arguably among the most powerful features of Cocoa. I built an app with a really complex, dynamic layout using them (look up "Panna" in the App Store). Working with an evolving design and changing team, with layout elements often changing and getting tweaked in tiny ways... Well, if I did the entire layout in code, I would have needed a full- time developer just for the ongoing GUI changes. I agree that dynamic layout support was weak pre-constraints, but it was still a much better development experience, and now you can do really complicated things without any code at all.

If you're just talking about some buttons in a toolbar, go nuts, but otherwise it's worth the time investment to learn.

<comment><USER11> 100% agree. IB makes for faster development time, easier maintenance, and it's way better for auto layout if you're targeting iOS 6.0

<comment><USER12> I think there's a case to be made though, that using IB when starting out doesn't make you fully understand how UIViews work. So starting out I'd probably recommend you make your own views programmatically to know what you're hooking into.

That said once you get that base level of understanding, nibs and storyboards are huge time savers, and are the way to go.

<comment><USER13> While using storyboards definitely meant that I didn't understand things like how my root view controller got set up, I don't think it abstracts too much. Most importantly, using Interface Builder allowed me to explore the properties of views and get immediate feedback on how they're made. I still go back to a Storyboard when I need to figure out what combination of UIControl content settings I need.

</comment></comment></comment></comment></comment></comment><comment><USER9> Pretty good tips. Re: being aware of retain cycles -- this is not just for blocks but really in general. When you start out you should immediately learn the conventions and adhere to them strictly. (Unfortunately the APIs don't always, I'm looking at you NSURLConnection!)

Another tip: try both Xcode and AppCode: <http://www.jetbrains.com/objc/>. It's a subjective thing but for myself AppCode is far better (it helps that I also use IDEA for Java, including Android).

<comment><USER14> As annoying as Xcode can be sometimes, I can't stand AppCode. It doesn't feel like a native app, and it seems very fiddly and even less user friendly than Xcode.

</comment></comment><comment><USER15> I've been programming iOS for a couple of years now and some of those tips where useful to me!

Anyhow as we're contributing top tips, my one is 'Always run your app on target hardware.'

Don't rely on the emulators, especially if your're doing OpenGL work. You will only know your framerate by running your app/game on the real hardware.

<comment><USER16> This is huge.

Running on the emulator is good if you haven't paid the $100 to put it on device yet. After that, you better be running on your device every time. There's so much to be said for actually holding the device and using your app like your normally would, instead of pointing and clicking with a mouse. Even the pixels and text-size/color are WAY different when on the device. Seriously, do this if you aren't already.

<comment><USER17> Well this is a bit of a sweeping statement.

I don't think you ALWAYS have to run on your device. Emulators are much faster at launching and getting to it. I use the emulator for a majority of quick fixes, layout changes, API debugging, etc. I move over to the device when things are nearing a point where I need to test real-world things.

Using the emulator is fine, just be sure to test on the device before you deploy.

</comment></comment></comment><comment><USER18> The thing I have missed the most with Objective C is the lack of a code tidy/formatting tool. All Xcode can do is alter the indent on each line which isn't useful. Regular indent etc do not support the language. There is an uncrustify tool in various SO answers but it is a good example of how not to do things (eg by default it does nothing - there are no presets, it is very flaky).

I wish Google provided tidy tools with their style guides, or Apple did something with Xcode.

<comment><USER19> Have you tried JetBrains's AppCode? <http://www.jetbrains.com/objc/>

(I haven't but their RoR-tailored IDE RubyMine is the only IDE I've enjoyed using after it for less than a week.)

<comment><USER18> I haven't but I did look at the page as it was linked in the article. I never saw any mention of code formatting. An example of what I expect is like the Eclipse Source > Format option which will go in and make everything consistent including making lines less than 80 chars, adding space around operators (I never put in spaces which goes against almost every style guide), ensuring the arms of if/else always have braces etc.

I actually do most of my iOS development by running emacs on my Linux box and using sshfs to access the files on the Mac. I use command line tools for compilation/running/debug. I did originally start out using Xcode but it gets in the way of the coding. (My work involves a library that functions in the background and has no user interface.)

AppCode hasn't seemed worth the effort to investigate and $200 is rather a lot to spend on a code reformatter. (Also only running on MacOS makes it significantly less useful to me.)

<comment><USER20> AppCode is $100.

$200 is you purchase a company license, which means anyone at the company can use it. If you are the only person using it, you only have to pay $100.

<comment><USER18> AppCode is $100 if you make the purchase using your own money and are not reimbursed in any way by the company. I try to keep work and personal stuff very separate and have no personal need for AppCode. $100/200 is still pretty steep for a code reformatting tool!

"If you, as an individual, are purchasing a product license using your own funds, then the personal license is right for you.

Personal licenses are not available to companies in any way or form. Transfer of personal licenses to any third party and/or reimbursement for personal license purchase by a company are prohibited by the Personal License Agreement."

<comment><USER20> Yes, I'm aware of this. I was simply clarifying the pricing is not $200, but $100 for a single-person license. There has been confusion in the past regarding this, people assuming that if you use one of their products for business, you must purchase a company license. Even if you only use AppCode for work stuff, you do not need to purchase a company license.

</comment></comment></comment></comment></comment></comment><comment><USER21> For starters, do go through the iOS development by paul hegarty videos from here, [https://itunes.apple.com/gb/itunes-u/ipad-iphone- application...](https://itunes.apple.com/gb/itunes-u/ipad-iphone-application- development/id473757255)

The 15 hours of video is the best investment of your time if you want to jump start into iOS development.

</comment><comment><USER22> CocoaPods (<http://cocoapods.org/>) is a really easy way to integrate 3rd party libraries into your iOS and OSX projects. It follows a similar pattern to bundler for ruby; you just specify a library by name and a version number in your Podfile and CocoaPods handles the rest. Another suggestion is to use categories on Cocoa classes for operations you do often. It cuts down on code duplication and makes your code more readable. One I use in every single project is a category on UIView allowing me to do such things as 'myView.x = 5.f' instead of pulling out the views frame, updating the frame and then setting the frame again. I also agree with the other commenters that IB should be utilized when possible. It makes iterating on UIs much faster, easier and less error prone. +1 for using blocks though, how did we ever get by before?

</comment><comment><USER23> I wished that when I started out with iOS development, that I knew that to get success on the App Store, 80% is marketing, and 20% is the quality of the app.

<comment><USER24> iOS development != App Store success. This would actually be my advice for anyone starting out:

1\. Make an app that looks awesome as a reference (and don't expect anyone to ever, ever use it)

2\. Get a job as an iOS contractor

3\. If you have enough experience _and_ a good idea, make your decision between a reliable cash flow and becoming an App Store cowboy. But only then.

<comment><USER23> Definately a good idea. Hopefully it will change so good apps will be more important than marketing, but this will only happen if Apple changes their App discovery...

</comment></comment></comment><comment><USER24> If you use ARC from the start, then can you really understand block retain cycles (which are just two bullet items below)?

I would absolutely try to write one or two "Hello World" apps without ARC first. CMIIW but Xcode will highlight any instance where you do things differently than ARC would, there is plenty of feedback on what you are doing. And once you feel confident enough, upgrading the project just takes a few clicks.

And I found ARC to be super easy not in spite, but _because_ I came from C++ :) it is shared_ptr vs weak_ptr all over again. Don't memcpy() them, don't create cyclic references, beware race conditions when testing if a weak_ptr is still there ...

<comment><USER25> I love your advice: start out learning how to manage memory and it only gets easier. While ARC is great compared to manual memory management, it doesn't work on non-Objective-C object, such as CFRefs (when dealing with sound, for example).

<comment><USER24> It's even worse when you have to mix CFRefs and Objective C. Without ARC you don't need any __keywords to do so, and when you switch you know where they come from.

</comment></comment></comment><comment><USER26> Mostly a really good list. My only nitpick is:

 _RegexKitLite - Powerful regular expression support_

Use NSRegularExpression instead. It's built into the OS (in Foundation) as of iOS 4, which is below the minimum target you have (if you support the iPhone 5).

</comment><comment><USER27> Thanks - as it happens I'm about 3 months in to learning Objective-c and iOS development. This is super helpful, as many of the tutorials online are dated. Right now I'm working through the Ray Wenderlich stuff which is really good, at least as far as I can tell.

w/r/t using the visual XIB/Storyboard interface vs. coding the views, I've found early on that while the nibs and storyboards make it easy to prototype and visually hook stuff up, looking at some of the apps I admire (apps like Clear, Rise, etc.), makes it pretty clear that I will need to code these views up myself to achieve some of those interactions. Unless I'm missing something (which of course I am, I'm a NOOB) I don't see how most of those can be done right from the nibs.

edit: also, if anyone has any other recommended links/resources, I'd love any recommendations. Thanks.

<comment><USER13> Eh, I wouldn't be so sure. I remember from the WWDC 2012 presentation that the iPhoto team talks about how they used xibs in their workflow, and iPhoto is an extremely impressive app. There's also the fact that you can do alot of setup with a xib or storyboard, and then do relational layout programmatically.

<comment><USER28> iPhoto is an interesting one: the _layout_ is done programatically, but the xibs are used to load the images. For example, the brush panel is all animated and arranged in code, but xibs are used to hold the brush PNG images since it reduces the code burden (of manually creating the UIImageViews, etc etc).

</comment></comment></comment><comment><USER29> Good article, I like these because there are a lot of things I wish I knew when I started iOS development as well 'back in the day' :) Couple nits:

-XIBs are awesome and you should strive to use them, falling back to layout in code when the XIB fails to meet your requirements. Though I'm also finding storyboards hard to swallow for complex projects. -Blocks and GCD are great tools but with great power comes a lot of complexity and consideration, they could easily get beginners in trouble. I ain't saying don't use em, but There Be Dragons Here.

Bravo on bringing up Singletons, thats something I only recently discovered and wish I had sooner. Also, I feel like a primer on delegates, protocols, notifications and selectors: when to use what and why, would also go a long way in the beginning.

<comment><USER30> My take is similar: I prefer XIBs, but I avoid storybords.

</comment></comment><comment><USER31> I would add Crashlytics (<http://try.crashlytics.com/>) to the list of good crash reporting services.

<comment><USER32> Seconded. I would add that crash reporting is pretty seamless with Crashlytics -- the dSYMs get uploaded automatically everytime you build (and it works with Jenkins too).

Don't know how things are with Testflight right now but when we worked with them last year we had to right our own script to upload the dSYM. Also Testflight does a lot more than just crash reporting so it might be too big a hammer if you just want automated crash reports.

</comment></comment><comment><USER33> Thank you. I'm hobby learning iOS development. Have some experience with C, but mostly knowledge of linux, java and devops stuff.

Here are the resources I'm using:

Started with: [https://developer.apple.com/library/ios/#referencelibrary/Ge...](https://developer.apple.com/library/ios/#referencelibrary/GettingStarted/RoadMapiOS/chapters/Introduction.html)

Then, plan to get a feel of the language will read [http://developer.apple.com/library/mac/#documentation/Cocoa/...](http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011210)

Then I was thinking to go watch [https://itunes.apple.com/il/course/coding- together-apps-for-...](https://itunes.apple.com/il/course/coding-together- apps-for-iphone/id537447071)

Also, a book that seems good to read [https://www.bignerdranch.com/book/ios_programming_the_big_ne...](https://www.bignerdranch.com/book/ios_programming_the_big_nerd_ranch_guide_rd_edition_)

Other suggestions and insights are appreciated.

<comment><USER34> This book was the most useful of the many iOS books I read when I was getting started.

<http://shop.oreilly.com/product/0636920023562.do>

</comment></comment><comment><USER35>
      Otherwise you can just use git submodules.

I would recommend against it. They become a real pain down the road.

I wish I had something to suggest as a replacement. We're still trying to figure that one out ourselves. We just know we won't use submodules again. For now, we're manually managing disjoint repositories.

<comment><USER13> The replacement is definitely the article's first suggestion: Cocoapods. Cocoapods is awesome and is rapidly being adopted by major repositories like AFNetworking, Kiwi, TTTAttributedLabel, MagicalRecord, and more: <http://www.cocoacontrols.com/cocoapods>

It has been super easy compared to git submodules.

<comment><USER35> Do you have a non-Apple-specific suggestion? We do cross platform development, so Cocoapods aren't an option.

<comment><USER13> Unfortunately, no.

</comment></comment></comment></comment><comment><USER7> My tip for beginners would be that while ARC is great if you use KVO you need to make sure that you consider the object lifecycles and remember to remove observers before they are deleted otherwise you risk occasional crashes in strange places.

</comment><comment><USER36> Can someone explain to me why I should use dispatch_once at all when a simple check whether the static variable is nil would suffice? It always seems so cluttered.

Compare this:

      + (MyClass *)sharedClass {
          static MyClass *_shared = nil;
          static dispatch_once_t onceToken;
          dispatch_once(&onceToken, ^{
              _shared = [[MyClass alloc] init];
          });
          return _shared;
      }

...to this:

      + (MyClass *)sharedClass {
          static MyClass *_shared = nil;
          if (!_shared)
              _shared = [[MyClass alloc] init];
          return _shared;
      }

Is there any difference regarding performance?

<comment><USER17> Should you call the singleton on multiple threads, there is a chance you could get inconsistent results based on a race condition. Using GCD ensures that the singleton is truly only created once.

</comment></comment><comment><USER37> I would highly recommend downloading and installing DCIntrospect[0]. It's designed to let you tweak layout in the simulator, but what it's really useful for is probing the UI in large, complex apps. Need to tweak the font size on a specific element, but you have no idea what that view class is? Enable DCIntrospect, click on the element, log its class name and properties. This has saved me, literally, hundreds of hours of debugging time over the years.

[0] <https://github.com/domesticcatsoftware/DCIntrospect>

</comment><comment><USER38> I've gotten bit a lot by putting a gesture recognizer on an UIImageView and forgetting to set the image view's userInteractionEnabled property to true.

</comment><comment><USER39> Good tips. Though I might say that for many tasks NSOperationQueue can be even easier/simpler for someone just starting out than GCD.

</comment><comment><USER40> Here's a quick tip: you can also disable arc for older libraries should you need to integrate them into your ARC project.

Just use the -fno-objc-arc flag ([http://stackoverflow.com/questions/6646052/how-can-i- disable...](http://stackoverflow.com/questions/6646052/how-can-i-disable-arc- for-a-single-file-in-a-project))

<comment><USER41> Alternatively you can also enable ARC for classes. This might be useful when you're working with a non-ARC project and want to include some ARC code. Use the switch -fobjc-arc to enable ARC for selected classes.

I'm currently using this switch to gradually migrate a non-ARC project to ARC.

</comment></comment><comment><USER42> Good list. There is some more great tips at [http://stackoverflow.com/questions/155964/what-are-best- prac...](http://stackoverflow.com/questions/155964/what-are-best-practices- that-you-use-when-writing-objective-c-and-cocoa) .

</comment><comment><USER43> Thanks for writing this, we're a bit beyond this stage but it certainly reiterates a lot of our learnings. Good to validate that i'm not insane or the only one feeling some of those pain points.

</comment><comment><USER44> Nice comment about ARC.

I think we need a few programmer generations until everyone is fine with some form of automatic memory management in all programming languages.

</comment><comment><USER45> Instead of manually running Clang's static analyzer (Build->Analyze), I'd recommend setting your project up to always analyze after building.

</comment><comment><USER46> Great tips!! I really hope I have read these tips before I start my last project, which I spent one night to make it localize...

</comment><comment><USER47> Wish this article was around when I started. These are all things I've learned to use and embrace every day. Great tips!</comment>


Vim plugin for Jupyter notebooks - <AUTHOR> https://github.com/goerz/jupytext.vim <comment><USER2> Jupyter notebooks appear as markdown documents or Python scripts in Vim. This is based on Jupytext, cf. [https://news.ycombinator.com/item?id=17950230](https://news.ycombinator.com/item?id=17950230)</comment>


Mars Colonial Transporter - <AUTHOR> http://en.wikipedia.org/wiki/Mars_Colonial_Transporter

<comment><USER2> A thought that occured to me recently is that one of the big challenges with moving bulk cargo to Mars is that we don't really have a proven system of landing large weights on the Martian surface safely. The best we've done so far is that Skycrane system for Curiosity, which doesn't sound like it would scale all that well to heavier weights.

Meanwhile, SpaceX is working on making their F9 first stage land on Earth under its own power. Very cool, and a nice cost saver if they get it working, but maybe not super-revolutionary.

Put those thoughts together, though, and it looks like the system used for landing the F9 would be very useful for landing a heavy shipment on Mars, and it would have already been proven on Earth.

<comment><USER3> Yeah, I think that's actually one of their explicit goals for developing that capability, besides the cost savings of fully reusable rockets.

</comment></comment><comment><USER4> If you haven't already, read KSR's Red Mars (the first of the Mars Trilogy):

[http://en.wikipedia.org/wiki/Mars_trilogy#Red_Mars_.E2.80.94...](http://en.wikipedia.org/wiki/Mars_trilogy#Red_Mars_.E2.80.94_Colonization)

</comment><comment><USER5> >> "By late-2012, additional information made public included that Musk envisions a Mars colony of multiple tens of thousands[4][5] with the first colonists arriving no earlier than the middle of the 2020s."

>> "In June 2013, Musk stated that he intends to hold off any potential IPO of SpaceX shares on the stock market until after the "Mars Colonial Transporter is flying regularly."

I've been hoping to get in on a SpaceX IPO for some time now. Looks like I'll be waiting a few more years... =/

</comment><comment><USER6> That cross section illustration makes the Falcon 9 look like a baby.

</comment><comment><USER7> Rekindling my excitement to see a demo of the Raptor engines.</comment>


NASA's Peer-Reviewed EM Drive Paper Has Finally Been Published - <AUTHOR> http://www.sciencealert.com/it-s-official-nasa-s-peer-reviewed-em-drive-paper-has-finally-been-published <comment><USER2> This was published November 17, 2016. It's been officially published for several months.

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

</comment></comment><comment><USER4> November of 2016

</comment><comment><USER5> There has been some good discussion on Reddit about how the thrust results shown in the paper are still most likely measurement errors due to thermal effects. It is a shame that they haven't released their actual data for independent analysis.

Link: [https://www.reddit.com/r/Physics/comments/5ewj86/so_nasas_em...](https://www.reddit.com/r/Physics/comments/5ewj86/so_nasas_em_drive_paper_is_officially_published/)

<comment><USER6> I've been following along on reddit on several subs, including the EMDrive sub.

This is a fascinating study about the politics and social aspect of science -- i.e., how it's actually done.

I'm just a layman, but so far it looks like this is experimental error. I never knew there were so many ways to screw something like this up!

Having said that, this is a win either way. It teaches all of us about rigorous science, it allows far-fetched ideas to be taken somewhat seriously as long as there is some sort of experimental evidence, and it provides a forum for practicing scientists and interested laymen to cross-pollinate. It's a really good thing. (Only probably no warp drive involved)

<comment><USER7> I agree this incident has educational value, because it's like a toy research project. The science behind the EM drive and the means to understand why it could never work are accessible to laymen who only have to trust our most well-tested physical laws.

If you're curious, you can find an easy to understand theory about why breaking the conservation of momentum lets you build a perpetual-motion machine, creating infinite energy.

Then, you can find a paper from the inventor of the EM drive explaining why it won't allow that to happen. His explanation spectacularly violates special relatively in a way we could easily detect.

<comment><USER6> Yeah, but it's more than just getting the natural laws out and beating people over the head with them -- there's emotional involvement from the public, and that's terrific.

For instance, there are quite a few hobbyests that are building their own rigs. There's discussion about noise control, radiation leakage, resonance, and so forth.

For the more theory-minded, there's a great discussion about empirical data versus theory, which you allude to. At the end of the day, of course, if you've got data, you've got data. Once the errors are taken out of the system, observation beats theory hands-down.

I know scientists would probably much rather have a conversation around "This is science, dang it, go read a book!" but for us layman schmucks, the really cool part is a conversation around "This is why science is what it is"

(Note: I'm not addressing you directly. I've just noticed a lot of mockery and impatience from some of the scientific community, and that's a shame. Better to use this as a teaching moment in my opinion)

<comment><USER8> >Once the errors are taken out of the system, observation beats theory hands- down.

But how do you go about distinguishing signal from noise? That's ultimately the reason data say far less, on their own, than they seem to: because interpretation of data is at least as important as how you collect them, but interpretation brings in all the gooey things people really want to wish away. Or put more bluntly, observation can't "beat" theory, because theory is the way you decide which observations to make, how to carry out those observations, and how to understand the products of the observation. Theory and observation are inseparable; in a sense, all observation is at once theoretical, and all theory is at once observational.

</comment></comment></comment></comment></comment><comment><USER9> Paper listed in article, [https://arc.aiaa.org/doi/10.2514/1.B36120](https://arc.aiaa.org/doi/10.2514/1.B36120), appears to cost well over a thousand dollars to access. I found [https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/201700...](https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20170000277.pdf) online; I think it's the same thing.

<comment><USER10> The first link loaded a PDF for me.

<comment><USER9> Ahh, it looks like I didn't notice the PDF link. My mistake.

</comment></comment></comment><comment><USER11> NASA has published this paper. These guys presumably know what they're talking about. Moon landing, space shuttle, Voyager, etc. They ran actual experiments on this drive.

Why are half the comments here saying 'They must be wrong' \- seemingly based on nothing more than a strong belief that NASA _must_ be wrong.

<comment><USER12> This is the worst part of the internet. Amateurs and 2nd year college students dismissing months/years of hard work by actual professionals. They take all this work and "hand wave" it away in less time than it takes to make coffee.

The internet is full of amateurs and they are very very confident about their abilities.

<comment><USER13> Professionals don't always get things right, either, and reactionless thrust doesn't really fit into our best current physical model. That doesn't mean it can't exist - but, given the general usefulness of our current model in predicting how things will behave, there's reasonable cause for extraordinary skepticism in response to claims that one of its "can't happen" conditions is inaccurate.

Maybe the paper's conclusion is accurate! Maybe this physical "can't happen" actually can, and the model needs extending to account for that. It wouldn't be the first time. But it also wouldn't be the first time that a "can't happen" really can't happen, and the result suggesting otherwise is an artifact of the way an experiment was run, rather than an accurate description of a previously unsuspected physical phenomenon. Going by past examples, the latter is much more likely than the former. So there's nothing unreasonable, even for people like myself who aren't knowledgeable enough to evaluate the paper on its own merits, in reserving credulity until the result is shown by other experimenters to be reproducible.

<comment><USER11> I totally understand some scepticism, but there appears to be the archetypal response of 'Oh, I bet NASA hasn't thought of _this_ ...' when it's inconceivable that NASA hasn't, in fact, thought of that.

Some of the most sensible comments I've seen here have basically said 'It seems to violate what we know of physics, so hopefully it's right and we have some interesting times ahead'.

It's the dismissal, out of hand, after a relatively extensive amount of research and study -- especially compared to what the armchair critics can supply -- that I find frustrating.

Yeah, sure, I get that it seems implausible, but it transcends hubris to _know_ that it's simply experimental error.

</comment></comment></comment></comment><comment><USER14> Seems like the previously leaked 1.2 ± 0.1 mN/kW is true. I look forward to seeing it tested in space to finally see if its real or not.

<comment><USER15> That's such a tiny thrust it might be quite difficult to measure in space. Orbits are complicated, what with complex gravitational variability of the Earth (mountain ranges, continental shelves, the fact it's not a sphere), the influence of the moon and sun, interaction with the magnetic field, solar winds, and down in low earth orbit even the last vestiges of the atmosphere.

<comment><USER16> Those forces are actually pretty well behaved and can be readily measured and accounted for. Also, light sails have a order of magnitude less power, and the Pioneer Anomaly [1] was smaller yet. Space is probably the best place to test something like this.

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

<comment><USER15> The Pioneer Anomaly was only detectable over several decades and a journey to the furthest reaches of the solar system. I'd expect a useful propulsion system to produce effects quite a bit more detectable than that.

This effect is about 1/25 the power efficiency of the lowest power ion thrusters. Output at this level over a very long period might be useful at the interplanetary level and maybe at geostationary altitudes, but the low earth orbit environment is actualy highly variable and unpredictable at this scale of effect.

<comment><USER17> Wouldn't variations in atmospheric drag negate any possibility of detecting the actual thrust component in leo? The trusts are small, as is the device, but any variation would be extremely hard to detect and measure. Please correct me if my line of thinking is wrong though, I'm not an aerospace engineer.

</comment></comment></comment></comment></comment><comment><USER18> The quote of interest (being able to be tested in months) references another article where nothing has been committed but could be done in 6 months.

On one hand it's great that this is being reviewed and tested. The other hand, that it's not getting properly tested in space where it really can make a difference is somewhat saddening. Can anyone point to a committed space trial?

<comment><USER19> Why would you test it in space?

I'm not sure I understand the reasoning.

<comment><USER20> The effects are small enough that there's some possibility that it's just measurement error. If you produce a drive that actually moves something in space, you have a real effect.

</comment></comment></comment><comment><USER21> What ever happened with the German result that showed no thrust when the device was hooked up to an on-board battery?

<comment><USER22> here: [http://emdrive.wiki/Experimental_Results](http://emdrive.wiki/Experimental_Results) seems to be all the experimental results collected so far from various labs around the world.

</comment></comment><comment><USER23> As always, the relevant XKCD: [https://xkcd.com/955/](https://xkcd.com/955/)

While I don't really believe it, I am intrigued by the possibility. It has been a long time since we learned anything truly new in physics. The recent breakthroughs (Higgs boson, gravitational waves, for example) were satisfying, but not surprising. I would desperately like to be surprised.

<comment><USER3> In case you missed it, the theory behind the EM Drive is also being used to explain galaxy rotation:

[https://www.researchgate.net/publication/313580454_Low- accel...](https://www.researchgate.net/publication/313580454_Low- acceleration_dwarf_galaxies_as_tests_of_quantised_inertia)

<comment><USER24> I don't know anything about this field but the language seems sound to me.

Is there a consensus on this interpretation v. "just adding more dark matter"?

<comment><USER3> It is unfortunate that the theory of Dark Matter doesn't have a cute parlor trick like the EM Drive.

</comment></comment></comment></comment><comment><USER25> Ugh, science alert. _sigh_</comment>


Facebook announces SPDY support - <AUTHOR> http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0251.html

<comment><USER2> It is not what the linked post announces. Quoting:

 _We currently are implementing SPDY/v2, due to the availability of browser support and the immediate gains we expect to reap. Although we have not run SPDY in production yet, our implementation is almost complete and we feel qualified to comment on SPDY from the implementor's perspective. We are planning to deploy SPDY widely at large scale and will share our deployment experiences as we gain them._

</comment><comment><USER3> Forced SSL is not a problem for big sites like FB and medium size sites, but it is incredibly problematic for the small sites with less than a couple of thousand visitors per month, in effect it means that SPDY (and eventually HTTP 2.0 unfortunately) will remain a bonus for the elite web sites while the majority of the smaller web sites will remain on HTTP 1.1 "forever".

Yeah, I'm aware that some providers like StartSSL hands out free SSL certificates, but I don't think it's a good sign of things to come that you need to hand over sensitive personal information in order to use the latest generation of a fundemental web technology. You'll also need a dedicated IP, which costs money and is becoming increasingly scarce and expensive.

I actually run a small web host for my clients and all of them have denied my offer to install a free SSL from StartSSL in order to get SPDY because of the privacy concerns and the extra cost of the dedicated IP they're required to get.

It's a shame that a large majority of the web sites on the net will become stuck on an old technology just because of an arbitrary requirement for encryption even though they have nothing to secure anyway.

<comment><USER4> I'd hope that anyone speaking SPDY would also be SNI-capable, thus negating the usual need for one IP+port per certificate.

Granted, it does nothing for your older non-SNI browsers, but they won't be speaking SPDY or HTTP/2.0 or whatever it winds up being called.

<http://en.wikipedia.org/wiki/Server_Name_Indication>

<comment><USER5> Android browser supports SPDY but doesn't support SNI.

<comment><USER6> Versions of Android that support SPDY also support SNI.

</comment></comment></comment></comment><comment><USER7> It's great to see how such a fundamental change in how browsers and servers communicate can get rolled out so quickly! I would have guessed that this sort of thing would require many more years of effort than it did.

The author of the post, however, does seem to misunderstand SPDY's server push feature. He states that Facebook requires a substitute for long-polling for low-latency message delivery, and seems to think SPDY provides this. Unless I'm mistaken and there's some Javascript API available, server push is merely for cache-priming and reducing latency of requested objects alongside a regular pageload (eg, push the CSS and images along with an html page).

<comment><USER8> I think this is a beautiful example of competition at work. Google Chrome enabled them to forge ahead of the other browsers to scratch their own itch. Facebook evaluated their work and it checked out, so it will become the defecto standard as others join in using it. Thus, standardiztions committees avoid clean room engineering and instead formalize proven implementations for broader distribution.

<comment><USER9> As a side note, "defecto standard" is a great turn of phrase which seems to never have been used intentionally. Googling it results in pages and pages of very serious documents which intended to use "de facto standard".

<comment><USER8> Really, that was just my iPad and autocorrect, followed by poor editing.

<comment><USER9> Yeah, I didn't mean to give you a hard time for the ipad autocorrect, I just thought the end result was funny.

</comment></comment></comment></comment></comment><comment><USER10> And here's Twitter's response to the same Expression of Interest too: [http://lists.w3.org/Archives/Public/ietf-http- wg/2012JulSep/...](http://lists.w3.org/Archives/Public/ietf-http- wg/2012JulSep/0250.html)

<comment><USER11> Twitter is already running SPDY, by the way. Here's a Firefox extension that shows a little icon on SPDY-enabled sites: <https://addons.mozilla.org/firefox/addon/spdy-indicator/>

</comment></comment><comment><USER12> On a side note: if you use Google AppEngine, you already have SPDY support (as long as you visit your app via SSL, which usually requires the .appspot.com domain). Of course, if some services you use _aren't_ served via SSL (I'm looking at you, Disqus!), then you get the big ugly 'mixed content' warning.

Moral of the story: if you run a web service with an API or embedded javascript module, make sure the entire stack can be run over SSL!

<comment><USER13> I thought they released ssl for custom domains at IO.

</comment></comment><comment><USER14> > "SPDY's header compression is a good, general-purpose solution, and gzip is > a good starting point, but we would prefer to see a more lightweight > compression algorithm for the HTTP/2.0 standard."

What's _more_ lightweight than gzip? DEFLATE?

<comment><USER15> Snappy is faster than gzip/zlib:

      "For instance, compared to the fastest mode of zlib, Snappy
      is an order of magnitude faster for most inputs, but the
      resulting compressed files are anywhere from 20% to 100%
      bigger."

<https://code.google.com/p/snappy/>

</comment></comment><comment><USER16> That's great news. But why is that FB's SPDY session never gets captured in chrome net-internals?

<comment><USER17> From the link:

 _Although we have not run SPDY in production yet, our implementation is almost complete and we feel qualified to comment on SPDY from the implementor's perspective._

<comment><USER16> That's great.. Looking forward to it..

</comment></comment></comment><comment><USER18> I'm actually a fan of the Trac software linked to in the article. It's hard to beat a combined Wiki, source browser and ticket management.

</comment><comment><USER19> a massive gain for FB would be pushing data to the browser rather than pinging for new data no? SPDY allows this</comment>


NPM, Inc. Announces Leadership Change - <AUTHOR> https://www.prnewswire.com/news-releases/npm-inc-announces-leadership-change-300922517.html <comment><AUTHOR> The schadenfreude in the twitter thread[1]is an interesting alternative perspective from the thanks and congratulations in the press release.

1\. [https://twitter.com/npmjs/status/1175095610602450944](https://twitter.com/npmjs/status/1175095610602450944)</comment>