Undebt: How We Refactored 3M Lines of Code - <AUTHOR> http://engineeringblog.yelp.com/2016/08/undebt-how-we-refactored-3-million-lines-of-code.html <comment><USER3> For Java, IntelliJ has a built-in version of this called "structural search and replace" [0]. This is incredibly useful when a library changes an API or you need to refactor a lot of similar code.

This feels relatively safe in Java because tooling can staticly know a lot about your code (and can know for sure that a particular call site is the method or class you're targeting). I've be terrified to do it in python without a very thorough test suite.

[0] [https://www.jetbrains.com/help/idea/2016.2/structural- search...](https://www.jetbrains.com/help/idea/2016.2/structural-search-and- replace.html)

<comment><USER4> IMO the main reason Python standard library is so wildly inconsistent. They don't really have the tools to migrate stuff painlessly and the 'batteries included' approach with weak versioning means you can't change stuff without breaking everyone who upgrades a python version.

<comment> vertex-four Even if they changed the standard library from version to version... the result would be that people would stop using the standard library, migration tools or no tools. Nobody really wants to deal with being pinned to a specific minor version and no older/newer - especially libraries.

<comment><USER4> The correct solution is to version the standard library separately from the language and allow for versioned dependencies, then a new language/VM update doesn't imply a new library that breaks everything, and vice versa.

But python grew up in an enviroment where this sort of thing was not practical, and the batteries included is actually a good approach for what python tries to do - scripting. It just doesn't scale well in to maintainability.

<comment> vertex-four Once you have the standard library split apart, you might as well split it up, though, and then you don't really have a standard library any more. You could go the Haskell Platform route... which isn't a wonderful idea.

<comment><USER4> I think if Python was developed from scratch now you would have a very small classic standard library and then stuff like HTTP server/client and JSON parsers would be separate libraries handled by package manager, but since python is a scripting language it would make sense to ship with some packages by default (so not a standard library, but say core packages) - this would let you version the core packages like any other package, but it would still let you run scripts without internet access/need to pull random dependencies for a script run.

<comment> vertex-four That is pretty much the Haskell Platform. Haskell people have issues with it because it contains a whole bunch of really useful packages, but essentially pins them at old versions globally. Upgrading them, then, is a global thing, and if someone depends on an older version... you're stuck.

The solution to this, of course, is sandboxing - never install libraries globally, only on a project-specific basis, and then their dependencies can override global ones. But it's fiddly to get the UX right - in Python, managing that involves two separate tools. And you'd need to create a project directory to get a repl with some library in it, unless you had extensions to the repl to install things temporarily - and then you'd likely have two separate UXes for installing things, whether you're doing it for a REPL or a project.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> "...time that could be better spent working on new features and shipping new code"

Can we please stop putting forth this idea that features >>> reliable product? The amount of dev time that a company will save from removing technical debt will likely be more than the extra sales the company will get from a new feature. I look forward to the day where the executive team comes to the developers and ask why they are working on features instead of cutting down technical debt.

<comment><USER6> There is an old Joel On Software blog post I was reading recently that talked about a methodology at Microsoft they called "Zero defects", where fixing known bug _alway_ had priority over working on new features.

<google google google>

Here - pont 5 in this post: [http://www.joelonsoftware.com/articles/fog0000000043.html](http://www.joelonsoftware.com/articles/fog0000000043.html)

<comment><USER7> Interesting. I recently read an article[1] where John Romero talks about the culture of early id Software and he mentions something similar:

> As soon as you see a bug, you fix it. Do not continue on. If you don't fix > your bugs your new code will be built on a buggy codebase and ensure an > unstable foundation.

Looking back to the codebases i've worked with, this advice seems extremely wise.

[1] [http://www.gamasutra.com/view/news/279357/Programming_princi...](http://www.gamasutra.com/view/news/279357/Programming_principles_from_the_early_days_of_id_Software.php)

<comment><USER8> I guess he forgot about this when making Daikatana? :-) Good advice nonetheless. It's a bit far-fetched, but reminds me of the "if you can do it in less than fives minutes, do it now" thing.

<comment><USER9> Obligatory mention of 'Masters of Doom'. I think Romero may have been a better programmer than first-time large project manager, but he wouldn't be the only one :)

</comment></comment></comment></comment></comment><comment><USER10> How do web applications explode out to 3 Million lines of code? Yelp, to me, looks like a typical CRUD app and I would have been surprised if it were more than 100,000 lines of code. The software I develop is pretty large and typically doesn't surpass 40,000 sloc written in-house (i.e. excluding third party libs).

Does anyone here maintain such large codebases? Are they truly that big or are people just counting third party code and generated stuff?

<comment><USER11> I maintain a line-of-business webapp that could be mistaken for a typical CRUD app, but actually has a lot of business logic enforced in code.

That's stuff you don't _have_ to hardcode -- you can pull it out into a 'rules engine' (at the expense of an additional runtime dependency) or push it further down into, say, database stored procedures (I can hear some of you shudder). But for us, the rules rarely change, or change at a pace that's acceptable to keep up with.

Also, there are a lot of views and specialized interfaces tailored for particular workflows. In several cases, the data underneath of them is the same, but there are different UIs -- that adds LOCs considerably.

<comment><USER12> I don't get the rules engine thing. It is still code. I rather have them hardcoded with proper source control and do frequent releases.

May be when you have rules that change every hour back and forth.

<comment><USER13> The difference is, I think, that you might want to be able to ad-hoc configure the rules without changing code. Going beyond that, you might want to allow people who are not developers to add/remove/change rules around business logic. Building all of this up can be quite an effort depending on how complicated the rules get.

</comment></comment></comment></comment><comment><USER14> It would be nice if some research institution would pay for the rehabilitation of some huge, bloated, ancient, but relatively unimportant app. Ideally by independent teams in parallel.

Just to get some real data on what works, rather than anecdotes from veterans.

<comment><USER15> Your comment opened my eyes. Considering the importance of software development in today's world ( and tomorrow's), the fact that those best practices or code management technics are found mostly in blogs, instead of scientific papers with proper experiments, tells a lot.

<comment><USER16> I don't follow. What does it tell?

<comment><USER17> Have you heard of the term/phrase "bro science" with respect to weight lifting? I'd draw an analogy between them.

Clarification: what I mean is there is a lot of ad-hoc stuff in these blogs that may be narrowly true or applicable to a given project or subset of a domain, but generally there is either significant evidence against some of these blogs' contents or the contents themselves have absolutely no formal, rigorous support.

<comment><USER16> I see your point, thanks. But the fact that not a lot of research _is done_ in this field doesn't tell you much about the validity of the non-scientific blogosphere findings, right?

Nice analogy btw.

</comment></comment></comment></comment></comment><comment><USER18> I have my doubts that a refactor that consists merely of more complex search and replace actions is a true refactor. Also, this reads more like an ad for their Python tool than about any lessons learned during this refactoring.

</comment><comment><USER19> It seems to me this is only going to handle the most trivial kind of technical debt. This kind of tool can't manage the way you organized your codebase, for instance. There's more to refactoring than find-and-replace.

<comment><USER20> Well even if it just gave you some reasonable abstraction over regex, at this kind of scale it seems useful. Plus I bet they had excellent test coverage, which really makes refactoring much easier.

</comment></comment><comment><USER21> I would also be interested the thought process in deciding what functionality to refactor. Did you review the code and identify areas before unleashing your tool on it?

With 3M lines of code gone, it must be terrifying to feel that it may have broken something. How did you ensure that it is still working as before?

Edit: Grammatic corrections.

<comment><USER22> I had to deal with many sizable codebases of legacy code over the years and even answered a similar question once on StackExchange. Apparently people liked the answer: [http://programmers.stackexchange.com/questions/155488/ive- in...](http://programmers.stackexchange.com/questions/155488/ive- inherited-200k-lines-of-spaghetti-code-what-now)

The question was within a somewhat specific context (team of scientists, visual programming environment, etc...) but I use the same approach for all projects. Never reached 3M LoC for a single projet or system component though. More like 1.5M. Anyways, that process works for me. Maybe it does for others.

</comment></comment><comment><USER23> This smells as being a need that comes as a consequence of using a dynamically-typed language. Because the example given seems to be just getting rid of the usage of a certain method, to replace with a new one. In a statically typed language, e.g. C#, you just mark the old method with an [Obsolete] attribute and go fix all the warnings. (Granted, a tool that replaces all these usages is also useful, but to me, there are much more complex ways of technical debt than just obsolete methods.)

<comment><USER24> In VS2015, showing all references to methods, props, classes, etc. is just one click away. Unfortunately it's not available in the community version.

[https://msdn.microsoft.com/en- us/library/dn269218.aspx?f=255...](https://msdn.microsoft.com/en- us/library/dn269218.aspx?f=255&MSPPError=-2147217396)

<comment><USER23> Use MonoDevelop/XamarinStudio.

</comment></comment></comment><comment><USER25> IMO a much better approach is JSCodeShift, which works based on the AST: [https://github.com/facebook/jscodeshift](https://github.com/facebook/jscodeshift)

</comment><comment><USER26> "Let a 1,000 flowers bloom. Then rip 999 of them out by the roots."

This is paraphrasing of Chairman Mao:

"The policy of letting a hundred flowers bloom and a hundred schools of thought contend is designed to promote the flourishing of the arts and the progress of science"

And the ripping out by roots part brings labor camps to mind:

"After this brief period of liberalization, Mao abruptly changed course. The crackdown continued through 1957 as an Anti-Rightist Campaign against those who were critical of the regime and its ideology. Those targeted were publicly criticized and condemned to prison labor camps."

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

</comment><comment><USER27> Related: [http://coccinelle.lip6.fr/](http://coccinelle.lip6.fr/)

Coccinelle is used extensively by Linux kernel developers for a whole tonne of things like this.

</comment><comment><USER28> * Newline at EOF

* Double quoted docstring

* Remove unused imports.

These things are largely cosmetic.

<comment><USER29> Indeed what i was thinking. A big refactoring is often structural, and changes the program in a bigger way. In Java you can actually easly move classes around by drag-n-drop and they code will refactor. In python this is impossible.

<comment><USER28> A big refactoring often means reducing the total amount of code you write to make it more readable. In Java it's usually going to be about 2x what the equivalent in python would be.

</comment></comment></comment><comment><USER30> Having an intern write a good blog post for the engineering blog is a great recruiting move.

<comment><USER31> Or a horrible statement at the level of company interest in tech debt - <USER2> problem given to the interns.

</comment></comment><comment><USER32> Refactoring... "puts a massive drain on developer time; time that could be better spent working on new features and shipping new code"

This is the wrong way to think. Refactoring will save time by making code faster, more reliable and making it easier to build those new features in the first place. Looks like their biggest issue is bad technical management, not deprecated code.

</comment><comment><USER33> Was the 3M LOC refactoring for yelp.com? The article doesn't say. How could possibly a review site have 3M LOC?

<comment><USER34> The front-facing system is the smallest part

The admin and back-office system is deeper. Beyond the reviews you also have: events, mailing list management, profile management, messages, i18n, search, etc

Example: [http://engineeringblog.yelp.com/2015/10/how-we-use-deep- lear...](http://engineeringblog.yelp.com/2015/10/how-we-use-deep-learning-to- classify-business-photos-at-yelp.html)

Edit: still, 3Mi lines is massive. However, I think there's something that contributes significantly: HTML and CSS

<comment><USER33> Hmm, well even with all those, the amount of code just blows my mind!

<comment><USER35> Once I was talking to someone from SAP. He told me about their Netweaver framework is 1 billion LOC and 40k SQL tables. That does not include any application, yet.

The biggest reason for the bloat: People are not allowed to change code. You only add code. Now try to add a button to some GUI without changing a single line of the existing code. At this moment I understood, why enterprises produce those overengineered AdapterFactorySingletonDecoratorBridge stuff.

</comment></comment></comment></comment><comment><USER36> The amount of code you have in a company is usually a function of the amount of engineers you have.

<comment><USER37> Sad. Hopefully that function is sub-linear.

</comment></comment><comment><USER18> A funny and relevant tweet:

[https://twitter.com/php_ceo/status/765298072691806209](https://twitter.com/php_ceo/status/765298072691806209)

</comment><comment><USER38> Google has a similar tool called Refaster

[https://github.com/google/Refaster](https://github.com/google/Refaster)

</comment><comment><USER39> The patterns that Undebt removes could be non-existent in the code base, but the conceptual, algorithmic design decisions and architecture could be all bad and that is what the actual technical debt is. Bad code patterns are just a tiny slice of the problem in most cases.

</comment><comment><USER40> If any of you guys are interested plotting total lines of code changes, do checkout [https://github.com/kaihendry/graphsloc](https://github.com/kaihendry/graphsloc)

</comment><comment><USER41> It's like codesearch [1].

[1] [https://github.com/google/codesearch](https://github.com/google/codesearch)

</comment><comment><USER31> The fact that you need a find and replace tool to make sensible changes to your codebase indicates that it's hugely out of control already.

</comment><comment><USER42> Interesting, I have always ( wrongly ) remember yelp as a Ruby Rails shop. Does anyone know the stack behind yelp?

<comment><USER43> It is mostly Python, both the monolith and SoA. A few services are Java, e.g. for talking to Lucene. The github site actually gives a reasonably complete view of the stack via the various tools we have for integrating with various parts of the stack. [https://yelp.github.io/](https://yelp.github.io/)

</comment></comment><comment><USER44> Is there a Haskell version for this?

<comment><USER45> Haskell code (as with LISP code) does not need refactoring. It always comes out as a distilled, pure and crystalline elixir of wisdom. :)

</comment></comment><comment><USER46> Why pyparsing, not ply or regex?

<comment><USER47> Jamie Zawinski <firstname.lastname@example.com> wrote on Tue, 12 Aug 1997 13:16:22 -0700:

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

<comment><USER48> "I've noticed that when I get quoted in .sig files, it's never any of the actual clever things I say all the time. Usually it's something dumb." \--Jamie Zawinski</comment></comment></comment>


Ask HN: Is it possible for a open source project to kill commercial competition? - <AUTHOR> I know, it sounds insane. But would it theoretically be possible for a passionate community/fanatic to make a system/piece of software/service that a corporation can't compete with without losing money?
For instance, if a system like Matrix included everything Slack and Discord charge money for free. Could that basically make people not want to pay for said features ever again, and get rid of the market altogether?
In theory something similar happened for programming languages and web browsers didn't it? <comment><USER2> Yes it did. Google's chromium project, Firefox, and webkit have combined to kill IE/Edge. The key difference with hosted applications IMHO is that the open source version needs to overcome the cost of hosting. For clientside apps that's less of an issue.

[https://www.theverge.com/2019/8/20/20813510/microsoft- chromi...](https://www.theverge.com/2019/8/20/20813510/microsoft-chromium- edge-beta-download-release-macos-windows)

</comment><comment><USER3> Linux and the BSDs killed the commercial UNIX market, at least mostly.

Back in the 1980s there were "cheap and cheerful" compilers such as Turbo Pascal, I think those have been squeezed between free tools and Visual Studio.</comment>


Facebook React.js License - <AUTHOR> http://www.elcaminolegal.com/single-post/2016/10/04/Facebook-Reactjs-License <comment><USER2> The way I read it, it's not evil.

It's a known and deliberate shortcoming of many licenses (e.g. BSD) not to include patent stuff because it makes everything unnecessarily complex. There was recently an article about why BSD and MIT are so popular, and it's because they're concise and understandable. There is a reason WTFPL exists and some developers resort to it as a way to avoid legalese.

Facebook clearly was aware of this "shortcoming" and being a big player, they might have wanted to be nice and say "we won't sue you for patent infringement if it turns out we have a patent on something React does". Then the managers went "but what if they sue us? Patents are not only for offense but also our defense, we would weaken our defense." And so the clause of "except if you sue us first" came into being.

And now this fuss about the patent part making it not an open source license? Oh come on.

I really don't like Facebook as a company, but this bickering is silly.

<comment><USER3> > _The way I read it, it 's not evil._

No, it's evil, full stop.

Facebook's patent policy means, in no uncertain terms: if you have a patent, they have a worldwide, royalty-free right to use it. Don't want to give them that? Well, until you remove all usage of Facebook's "open source" code, that's the situation.

Note: RocksDB also has this problem, which means CockroachDB is also infected. Tread carefully.

\-----

Note to downvoters: No one has a problem with Apache 2-style patent- retaliation provisions. Facebook could solve this problem TODAY by switching to that.

They don't because they don't want to retaliate, they want access to unrelated patents from third-parties at zero cost, with a credible threat to damage those third-parties if they want to retain their unrelated patent rights. There's _literally_ no other reason for Facebook to demand terms beyond Apache 2 than to do what I just described.

The Apache 2 license protects Facebook and third-parties and is 100% ethical. Facebook's patent position is not, for the reasons I've stated above. The community, IMO, should shun Facebook LOUDLY until they relent and stop this bullshit.

\-----

Update 2: It's actually worse, because Facebook tends to do this bullshit on stuff like RocksDB and React which are _incorporated_ in other software that you use to run your business.

Using a React-based dashboard widget for your ElasticSearch cluster? Good luck suing Facebook for patent-infringement, because guess what? _You agreed to let them infringe by using it_ , even though you didn't intend to.

Facebook's patent policy requires _constant_ policing to avoid. Like I said: EVIL.

<comment><USER4> > Good luck suing Facebook for patent-infringement

Protecting from patent lawsuits is not evil as SW patents are bullish anyway. No one except maybe some patent trolls or some other big companies will sue Facebook for patent infrigment and if they do then this is a pretty clever defence. If you really really have something really really unique invented (which is really really unlikely) then just don't use anything by Facebook.

<comment><USER5> Are you permitted to counter-sue if FB trolls _you_?

<comment><USER6> Yes you are. Facebook's patent grant explicitly allows the entity they're suing to counter-claims without losing the right to use Facebook's code.

</comment></comment></comment></comment></comment><comment><USER7> Version 2 of the Apple Public Source License includes the following termination clause:

12.1 Termination. This License and the rights granted hereunder will terminate:

…

(c) automatically without notice from Apple if You, at any time during the term of this License, commence an action for patent infringement against Apple; provided that Apple did not first commence an action for patent infringement against You in that instance.

Like the React patent grant, this applies to _any_ patent suit, not just ones that allege that the covered software infringes. The Open Source Initiative considers APSLv2 an Open Source license, and the Free Software Foundation considers it a Free Software license. Note that this clause terminates your _copyright_ license, not merely your patent license - it's significantly stronger than the React rider.

So I think the claim that it's not open source is a bit strong, even though I find this sort of language pretty repugnant.

<comment><USER8> Microsoft is not necessarily a paragon of open source, but many of their open source projects use unadulterated OS licenses.

Typescript is Apache 2: [https://github.com/Microsoft/TypeScript/blob/master/LICENSE....](https://github.com/Microsoft/TypeScript/blob/master/LICENSE.txt)

Visual Studio Code is MIT: [https://github.com/Microsoft/vscode/blob/master/LICENSE.txt](https://github.com/Microsoft/vscode/blob/master/LICENSE.txt)

<comment><USER9> You will notice that most new projects all use MIT. Apache 2 hasn't been used for anything new in the last year+.

<comment><USER10> Have some examples?

The MIT license is problematic with software patents.

I see some projects moving to Apache2 for that reason (one prominent example here is Rust. They moved to an MIT/Apache2 dual licensing model).

<comment><USER11> What is the problem with the MIT license and patents?

The MIT license grants explicit rights to deal in the software without restriction.

<comment><USER12> A copyright license is not necessarily the same as a patent grant... Apache 2 does contain a patent grant, and an even bigger nuclear deterrent similar to Facebook's separate grant with MIT.

<comment><USER11> The MIT license is not a copyright license (though, copyright is claimed). It is a license for unrestricted dealings in the software subject to certain conditions (no warranty or fitness, appropriate notices given, etc.).

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Hi, Paul from the React team here. There have been lots of questions about the license+patents combo we use. Recently our legal team answered some of those questions.

[https://code.facebook.com/license-faq](https://code.facebook.com/license-faq)

<comment><USER14> Is there any talk within Facebook on amending this clause or moving React to a standard license? I believe it's stopping a lot of large companies (whom the patent clause could actually affect) from using React, and all other like- licensed Facebook software.

<comment><USER15> Just use Polymer, vue or something else without that problem :-)

<comment><USER16> Facebook patents that apply to React will also very likely also apply to Vue or any other virtual DOM library. Using Vue makes you more vulnerable, not less, since you no longer have the protection of the React.js patent grant.

<comment><USER17> You made this assertion before, but it's wrong and dangerous. Without knowing what the patents are, you cannot possibly say whether or not OTHER technology is infringing on it. It is especially bad considering you are not a lawyer, nor have professed any familiarity with the patent process.

It is a moderate, but known, amount of work to look through FB's patents, assess which are likely around React, and read through the claims. Considering it's possible, I certainly think that it's reasonable to ask you to do the work, or stop making the assertions.

<comment><USER16> But I have been told, by lawyers, never to read patents, because that could triple damages for knowledgeable infringement.

It also doesn't address potential patents that are still within the 18 month filing window and are still secret.

<comment><USER17> Then don't make the assertion.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> I agree. I was working at a somewhat large IT company (~30k employees) this year. I made a plea for React and while our development section agreed, it got bounced by legal because of these points.

If Facebook is really serious about Open Source, they also have to make their licence so that every organisation is free to use it.

<comment><USER19> Being "serious about Open Source" doesn't mean a commitment to do anything to support people using your software.

It's the opposite, actually: the original copyleft licenses such as the GPL were explicitly designed to promote Open Source by hindering adoption in some cases, namely those where companies want to distribute derivative works commercially.

Then the BSD/MIT-style licenses weakened this restriction. So you're free to use React in a commercial product.

But Facebook, Apple etc. care a lot about patents these days. Not offensively, as far as we can tell, but they have now been burned repeatedly by often trivial patents being used to extract hundreds of million from them.

So they added these 'patentleft' clauses to their licenses to essentially undermine the patent system in regards to software. As it gets more difficult to build anything without some library that includes this clause, fewer and fewer actors will have the freedom to sue without consequences.

Being opposed to patents on intellectual property in the first case, I can only applaud these efforts. In fact, they should probably go further and extend the protection to everyone: If you use IP patents against Jane Doe, you may no longer use React.

The only problem is the rise of entities focused entirely on patent- litigation.

<comment><USER20> > It's the opposite, actually: the original copyleft licenses such as the GPL > were explicitly designed to promote Open Source by hindering adoption in > some cases, namely those where companies want to distribute derivative works > commercially.

I'm usually not the one to defend GPL but I want to point out that AFAIK distributing derivative works commercially is totally fine for GPL - you just have to follow the rules in the license (provide source code under the same licence).

</comment></comment></comment><comment><USER21> So, assuming you actually have a patent, and Facebook actually decides to infringe on that patent, the worst case scenario is that you lose your license to use React. There are principles of fairness and equity in the law that would allow you to stop using React in a reasonable amount of time. So write your frontend in Elm. It probably needed a rewrite anyways.

<comment><USER22> > the worst case scenario is that you lose your license to use React.

Not even that; you lose your license to use the patents Facebook has which cover React...

...if they exist. Nobodies ever found one, and a core React dev is on record saying he doesn't know of any either. :)

But you don't ever your license to use React. Bonus: Many people think the BSD license contains an implicit patent grant, which might well cover you even if the explicit patent grant is revoked. Again, if there are any patents to license.

</comment></comment><comment><USER23> Does this mean that react could be considered "available source" instead of "open source?"

<comment><USER24> I think it's a great illustration of the difference between "open source" and "free software." In this case the source is still openly published, but under certain circumstances you're no longer free to redistribute.

<comment><USER25> Personally I think it's a great illustration that even software developers lack reading skills.

Open Source means this, no more, no less: [https://opensource.org/osd- annotated](https://opensource.org/osd-annotated)

<comment><USER24> A license (such as Facebook's) that prevents me from redistributing a modified version could still qualify as "open source" so long as simple mirroring wasn't restricted.

> In practice, open source stands for criteria a little looser than those of > free software. As far as we know, all existing released free software source > code would qualify as open source. Nearly all open source software is free > software, but there are exceptions. First, some open source licenses are too > restrictive, so they do not qualify as free licenses. For example, "Open > Watcom" is nonfree because its license does not allow making a modified > version and using it privately. Fortunately, few programs use such licenses.

> Second, and more important in practice, many products containing computers > check signatures on their executable programs to block users from installing > different executables; only one privileged company can make executables that > can run in the device or can access its full capabilities. We call these > devices "tyrants", and the practice is called "tivoization" after the > product (Tivo) where we first saw it. Even if the executable is made from > free source code, the users cannot run modified versions of it, so the > executable is nonfree.

> The criteria for open source do not recognize this issue; they are concerned > solely with the licensing of the source code. Thus, these unmodifiable > executables, when made from source code such as Linux that is open source > and free, are open source but not free. Many Android products contain > nonfree tivoized executables of Linux.

[http://www.gnu.org/philosophy/open-source-misses-the- point.h...](http://www.gnu.org/philosophy/open-source-misses-the-point.html)

(Pasted the most relevant portion in case you lack reading skills.)

</comment></comment></comment></comment><comment><USER26> After _Alice v. CLS_ , what patents about React could be enforced?

edit: After Alice there has been a software patent massacre: [https://en.wikipedia.org/wiki/Software_patents_under_United_...](https://en.wikipedia.org/wiki/Software_patents_under_United_States_patent_law#Post- Alice_period)

<comment> joatmon-snoo IANAL but OTOH I would argue that _Alice_ isn't very relevant here. The chief rationale behind that case was the triviality of the core algorithm being described: if there isn't enough money in an account, you don't withdraw money from the account.

</comment></comment><comment><USER25> Facebook's license is even weaker than a BSD/MIT license without any PATENTS license attached at all. Because in that case the patents grant can be considered _implicit_ , depending on jurisdiction. By including a PATENTS license in that repository, Facebook nullifies the possibility of such a defense.

<comment><USER27> I wish he went into more detail on the difference between this and the Apache2 patent grants.

I've been favoring Apache2, and am considering adopting the GPLv2 compatibility clause that is being added to Swift.

<comment><USER25> Apache 2 is definitely much better.

IANAL, but I've written about the difference in another comment: [https://news.ycombinator.com/item?id=12692852](https://news.ycombinator.com/item?id=12692852)

</comment></comment></comment><comment><USER10> While we are on the subject:

I constantly find the need to read up on licensing. Usually with various blog posts or online information, which never gives me the feeling that I fully understood the legal implications or the context.

Can anyone recommend a book covering software licenses in depth? (ideally not only US centric)

<comment><USER28> With a new package manager every year, a new framework every six months, and a new build system every month, who has time for that? Just trust the masses: whatever frameworks and libraries have the most stickers on Macbooks has proven its veracity. /s

</comment></comment><comment><USER29> These conspiracy theories are really getting old.

Do people really think Facebook developed and released React for the sole, or even primary purpose of gaining patent rights? It's preposterous that so many top engineers would be working on such a goal.

It seems obvious that Facebook just has some overly cautious lawyers. I highly doubt that means Facebook is going to use your usage of React as an excuse to steal your patents.

<comment><USER30> Perhaps. But what if Oracle buys facebook or Zuckerberg steps down and a litigious CEO takes over. This is a major concern for lawyers in large companies.

<comment><USER29> I'm happy to recommend that everyone stop using React if Facebook ever sues someone for using React. But it remains a very unlikely possibility, especially since we don't even know if Facebook _has_ React patents.

<comment><USER31> Right. After you've spent 10+ man/years developing an app based on React / other lib with similar restriction. "stop using React" is fine advise for small projects that can be rewritten in few months by few people. For very large projects the cost of stop using / rewrite could be huge.

<comment><USER32> But utterly dwarfed by the cost of an offensive patent infringement lawsuit against a $300+ Billion company.

<comment><USER29> Exactly. If you're actually in a legal dispute with Facebook, the cost of rewriting your frontend to not use React is minimal.

It's not like React is a massive library with a huge surface area. Even a fairly complex application could be migrated to an alternative like Vue.js if the need arose.

<comment><USER28> > the cost of rewriting your frontend to not use React is minimal

Or a non-issue if you choose a framework that you feel has safer licensing.

</comment></comment></comment></comment></comment></comment></comment><comment><USER33> If companies fear that if they try to enforce their patents they will lose access to significant commercial opportunities as a result of not being able to use projects such as react...

...basically, I welcome it.

Patents are harmful.

The FSF has, to my knowledge, made no meaningful progress in significant patent reform.

If this helps, then bring it on.

<comment><USER34> Facebook's patent license doesn't grant you any patents outside the ones used by React.

It does grant them freedom to use any patent you may have (if you use their software).

See the problem? Even if you don't like patents, it makes the playing field totally uneven.

<comment><USER19> It still lowers the value of IP patents, since that value has most often manifest itself in suing Facebook/Apple etc.

With their value being even marginally reduced, maybe some patents will never be filed, or the value proposition of setting up patent-litigation entities is reduced enough to discourage it.

Basically this is net-positive for anyone who doesn't own or plan to own patents, even if it is even better for Facebook.

<comment><USER34> Patent litigation against such companies is often carried out by specialized entities, so those have nothing to lose by having their "React" patents revoked.

</comment></comment></comment></comment><comment><USER35> I worked with a development manager headhunted from Microsoft, who was quite worried about simple "Taint" from open source software (i.e. ideas gained from viewing open source code making their way into closed source software). I also worked with a company which wouldn't accept code contributions to their OS project; they would do clean room implementations to avoid the legal hassle of incorporating code which wasn't written for hire. So I can certainly see large companies being leery of utilizing software with licenses which don't include patent grants.

Perhaps it's less of an issue with the BSD style licenses, as explicitly called out in the article.

</comment><comment><USER36> To me it's the GPL of patents; it's a viral anti-patent license. Once you use React you must disarm in the destructive patent wars. I wish more popular software were released with it.

<comment><USER37> it's not really viral... the viral aspect of GPL is that any derived work you distribute would automatically have to be open.

in the case of the patents, they're not really used to create a derived work. As a result, there is no "infection".

<comment><USER12> I liken it to a mutually assured destruction aka nuclear deterrent. Which is a pretty close fit. As someone who is opposed to software patents in general, I'm okay with this.

</comment></comment></comment><comment><USER38> If it becomes a problem, you could drop in a react-compatible library pretty quickly. React native might be tougher but still would probably appear if there was a case with a lot of publicity.

<comment><USER39> So happy [https://preactjs.com/](https://preactjs.com/) and others are around

<comment><USER40> Other frameworks could infringe the hypothetical React-related patent. There is no safety from infringement as long as software patents exist.

<comment><USER12> Personally, I'm opposed to software patents... that said, there's no safety from any third party wrt patents either.

<comment><USER40> I think there exist fields of invention where it's reasonable for inventors to know what's in the patent database and thus avoid unintentional infringement. Obviously software isn't one of those fields.

<comment><USER12> When it's a case where it's not possible to utilize patent research in order to help make something, and in fact ill-advised to do so, then in that space the entire purported purpose of patents in that space invalidates their use.

</comment></comment></comment></comment></comment></comment><comment><USER41> I wonder what the OSI and Software Freedom Law Center say about this.

</comment><comment><USER42> "It is unknown to me why Facebook issued an Additional Grant of Patent Rights in the first place."

STOP RIGHT THERE

If you can't be bothered to do the research necessary to see why then your JD didn't teach ya much in the ways of learning about things. Which ideally should be a large portion, those big books of case law, now oft replaced with speculation and internet comments, do at least tell the story of "why". And if you jump the gun on researching the imminently googleable first sentence of your argument, how can I trust, nay, why should I trust, a single sentence thereafter.

Long and short APL has patent clauses, BSD doesn't, their PATENTS file kinda added that back to BSD without some of the apparent downsides of the APL in terms of forcing you to never ever sue about patents.

Small but not hard, I know, I just have a PhD not some fancy JD, but at least I can do the research that would've muted I imagine the entire post.

I still can't seem to write non-confusing sentences though. Oh well. Parse the above at your own peril.

</comment><comment><USER43> "A. The Additional Grant of Patent Rights in Unnecessary."

This is legally incorrect.

". But I've never heard any lawyer postulate that that document does not grant a license to fully exploit the licensed software under all of the licensor's intellectual property. Anyone who pushes that view is thinking too hard."

Nobody has pushed this view.

However, the author seems to miss that such rights are likely _not_ sublicensable, because they are implied, and implied rights are pretty much never sublicensable.

That is, i may have gotten the rights. That does not mean i can _give someone else the same rights_.

Now, there are other possible principles, such as exhaustion, that may take care of this (it's a grey area)

But it's definitely not the case that implied patent rights are somehow going to be better than an explicit grant.

They are for people _using_ software. They are not for people distributing software.

</comment><comment><USER44> Email I just sent the OSI:

Please see here: [https://news.ycombinator.com/item?id=12692552](https://news.ycombinator.com/item?id=12692552)

It turns out companies are now "bastardizing" the license terms. I would love for the OSI to re-evaluate if these licences are truly open source. Open source covers freedom, and I should think that these clauses abridge that freedom since it is very well possible for a company to be required to sue Apple or Facebook over patents. If that unrelated lawsuit "strips" your legal right to use software, that is NOT freedom.

Thanks

<comment><USER19> The OSI are opposed to software patents anyway, so I doubt that they have a problem with them becoming worthless.

"Freedom" is an empty slogan in this regard. Copyleft licenses have long restricted your freedom, the idea being that there are colliding "freedoms" under some circumstances and it's for the greater good of society to restrict some peoples "freedom" (those creating derivative works) for the benefit of of the end-user.

</comment></comment><comment><USER45> I think the change in licence has something to do with mobile phone licence issues, React Native had its first official release on a date that correlates to the licence addendum changes, this is the first official tagged release :

[https://github.com/facebook/react- native/releases/tag/v0.14....](https://github.com/facebook/react- native/releases/tag/v0.14.2)

As you can see it is dated: "10 Nov 2015" shortly after the licence was changed.

</comment><comment><USER46> One interesting thing to note is that the actual license makes no specific references to the patents rider, and in fact the patents grant rider is a separate file completely. Does that mean that I have to follow it, if it's not directly in the license? If we look at the license as a contract, shouldn't it be in the license directly, even if it's referencing something outside?

</comment><comment><USER47> I'm not sure why they didn't just use the MS-PL it sounds like the same thing? I don't understand why use BSD if the MS-PL achieves what they want, and is backed by Microsoft (surely it would be in their best interest to defend their own license).

[https://opensource.org/licenses/MS-PL](https://opensource.org/licenses/MS-PL)

</comment><comment><USER37> if a person offers two licenses, and you only need to accept one of them to be licensed, then you should be all set.

If I sue facebook and they countersue, then my defense is simply "i am licensed under BSD". The fact that you offered an additional license (they even call it "additional") does not mean that I am required to accept it when the first license stands alone.

Right?

<comment><USER48> Yes, but Facebook didn't dual-license this, they licensed it under a modified version of the BSD license. So it's that license or nothing. Edit: good point, gcp.

<comment><USER34> You misunderstood. He says "I'll take this":

[https://github.com/facebook/react/blob/master/LICENSE](https://github.com/facebook/react/blob/master/LICENSE)

which by admission of the blog post this is about, _already_ includes an implicit patent grant on React.

And he'll pass on this:

[https://github.com/facebook/react/blob/master/PATENTS](https://github.com/facebook/react/blob/master/PATENTS)

Which is marked as "additional".

<comment><USER43> This is a reasonable argument, given the headers says " * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. *"

However, the problem you have here is there literally can be no implied license when an explicit one is offered. You can't say "i take the bsd and implied patent license".

So if you want to take it without the additional rights grant, you can. But you won't get patent rights, because they have offered them to you explicitly under a different license.

</comment></comment></comment></comment><comment><USER49> Unrelated to the actual content of the page.. but why does this site require 1.25Mb of javascript to load? It makes up nearly 70% of the entire page, and is responsible for almost 60% of the requests needed to render the page. Do you really need to use that much javascript just to render a blog post. Why?

Those webfonts also took multiple seconds to retrieve leaving the page essentially completely blank to visitors until their browsers finally pulled them down. It paused long enough I was wondering if HN had sent sufficient traffic to bring the site down.

Here's an output to a quick stab at loading the page using pingdom: [https://tools.pingdom.com/#!/cpZuGy/http://www.elcaminolegal...](https://tools.pingdom.com/#!/cpZuGy/http://www.elcaminolegal.com/single- post/2016/10/04/Facebook-Reactjs-License)

<comment><USER50> Because it's a basic site with a handful of pages with a blog that is built as a single page app. All the HTML of the page is generated by Javascript and dumped into the lone div inside the body. So, you take the big hit at first load but then it's snappy after that.

Although, I would think the load size and speed for such a basic site would be better with standard HTML for everything but the blog.

Also, the main JS file is 1690 lines long and even though it says it is min in the file name, it doesn't seem to be minified.

The CSS file has some nice stuff going on in there. Some of the selectors are a bit long for my tastes though.

</comment></comment><comment><USER51> This has been a major issue for me from the get go, it goes against open source culture but that's no surprise because that is what Facebook loves to do (which it has consistently proved).

They pick something upcoming, recreate it injecting their ideals while knocking the original. They then release it to a sea of "pseudo developers" that latch onto it with the "well it's good because Facebook" mentality which aggressively defend it giving them more leverage.

Then they rinse and repeat until they have replaced everything the community has created with their equivalent instead of contributing back to those projects like a true supporter of open source would.

Open source is much more than having code on a repo, it's a culture that Facebook is hell bent on "changing".

</comment><comment><USER52> interesting article about why startups should never use Reactjs because if it's license

[https://medium.com/bits-and-pixels/a-compelling-reason- not-t...](https://medium.com/bits-and-pixels/a-compelling-reason-not-to-use- reactjs-beac24402f7b#.i625jul0b)

</comment><comment><USER53> How is this any different than the MPL 1.1 license? Section 8 of the MPL 1.1 has similar language.

/b

<comment><USER34> It's completely different.

MPL 1.1 talks about "such Participant's Contributor Version directly or indirectly infringes any patent"

Which refers to the software itself. Which means it's a patent retaliation clause similar to the one Microsoft and Google use. If you claim patents on someone for using specific software, you lose any patent licenses for said software that were granted to you. But in Facebook's case, the retaliation extends when you make _any_ patent claim on _anything_ Facebook does, even if it's completely unrelated to the software in question. Meanwhile, the patent license that Facebook gives you does _not_ extend beyond the software in question.

So you're effectively licensing _all_ your patents to Facebook, and Facebook _only_ gives you the ones you need to use the software.

</comment></comment><comment><USER54> So I checked StackExchange's law site and found this question - thus far unanswered, but those would be my questions exactly:

[http://law.stackexchange.com/questions/14337/q-about- consequ...](http://law.stackexchange.com/questions/14337/q-about-consequences- of-a-software-license-amendment-regarding-patents-facebook)

It comes down to two questions (quoted from the linked question) - note that those are _questions_ , not assertions:

1)

      > ... if we use any of Facebook's open source projects Facebook can violate *our patents* (of any
      > kind) pretty much with impunity: If we try to sue them we lose the right to patents covering their
      > open source projects(?)

2)

      > I have read opinions that other open source projects that don't have such a clause, for example
      > those from Microsoft or Google, nevertheless have the exact same problem, only that it isn't
      > explicitly stated. Is that true? Is my situation not any better when I only use open source
      > projects without such a clause?

I think that is a good point. The many opinions I see are almost all from people who don't have their own patents to think about, but what happens if you are a company and you do? Would you basically allow Facebook to use any of your patents, because for all practical purposes you can't defend them if you rely on their open source projects?

<comment><USER34> 1) Yes, and that's exactly the problem raised here.

2) The patent grants from Microsoft and Google grant a license on software (or a standard), and only give them a (reciprocal) license on the software or standard that is under consideration. If Microsoft had published React, you could still sue them for violating patents that are unrelated to React without losing your license to use it. The Facebook grant doesn't have this, so if you rely on React you can't sue Facebook at all. But _they_ can still sue _you_.

<comment><USER55> 2) If Microsoft published React without a patent rider, and Microsoft had patents on the tech in React, then you would be in violation in the first place, right? Microsoft can still you sue for violating their React patents, especially if you sue them first.

<comment><USER34> 1) The article points out there are implicit patent grants if they're not expressly spelled out.

2) Microsoft has provided patent grants that are less severe than Facebook.

</comment></comment></comment></comment><comment><USER56> Frankly multiple developers don't really care about the licenses or clauses. Software veterans and corporations care about it more than anyone else. Even the article is kinda hard to grasp in one go that I had to read a couple of times. To find the nuances in an OSS license and to think and act on it is not easy for a lot non native English speakers. And more posts like these are needed to make many people read and know about these serious issues.

</comment><comment><USER57> I'm not a lawyer so I can't say with certainty, but I'm sure Facebook could make React's license a bit nicer in some ways.

But I can't buy it as a reason for not using React, that sounds bogus to me. Facebook isn't gonna come sue your beer-ranking app company over a patent beef.

<comment><USER34> The Facebook competitor that is considering buying out your beer-ranking app making company might reconsider, though.

</comment></comment><comment><USER58> Similar approach to the patchwork of various patent grants on Opus implementations; it's still open source, it just might not be free for 100% of the purposes you could think of.

I think Robert doesn't understand that _open source_ refers to the _source code_ being _open to use, derivation, and study_. The BSD license also includes a warranty disclaimer, which is the exact same kind of protective language as the patent grant. The Facebook arrangement meets all of those requirements with the one stipulation that you forfeit the license when you enter patent litigation against Facebook for a counterclaim the granted patents or primary litigation for unrelated patents. I don't consider countersuing Facebook for patents applying to React, while USING REACT, to be a serious fundamental software freedom.

<comment><USER59> > The Facebook arrangement meets all of those requirements with the one > stipulation that you forfeit the license when you enter patent litigation > against Facebook for the granted patents. I don't consider suing Facebook > for patents applying to React, while USING REACT, to be a serious > fundamental software freedom.

Where does it say that the stipulation refers only to patents applying to React?

<comment><USER58> >Apparently in response to criticism, in April 2015 Facebook issued a second version of the Additional Grant of Patent Rights that softened the termination provision to say that the React software licensee would not lose its right to use the software under Facebook patents in the special case in which the licensee brings a patent lawsuit that is a counterclaim against Facebook or its affiliates that is unrelated to React.js. The second version of the Additional Grant of Patent Rights, in addition to the BSD license, is what governs use of React.js today.

Sorry, seems it only applies to counterclaims.

</comment></comment></comment><comment><USER60> So this attorney's problem is that rather than ambiguously granting a license to the patent claims necessary to implement this software, they decided to explicitly grant such rights? I see no problems.

<comment><USER34> No, his problem is with the breadth of the patent assertion Facebook makes. He's not the first to point out it's unusually in favor of Facebook, even compared to patent grants from Microsoft and Google.

</comment></comment><comment><USER61> For some reason, I have NO idea why, just like Angular. Just something kind of cool about it. React I'm sure is awesome, but Angular just seems to have something special. Just that extra "something."

</comment><comment><USER62> Other Open Source licenses have patent termination provisions. Apache 2.0 (which React used to use) says "If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.". There are other licenses as well that include more extensive patent termination provisions, such as the APSL.

<comment><USER63> The author covered this: "Facebook is not saying only that a licensee's rights to use React will terminate if the licensee claims patent infringement by the React library itself. ... Facebook is using its publication of React source code as leverage to win some protection against patent lawsuits generally."

</comment></comment><comment><USER64> I feel like if React doesn't "count" as open source software, then neither should anything licensed as GPLv3.

<comment><USER65> How are those things related at all in the context?

</comment></comment><comment><USER66> The argument that "This is Not Open Source Software" feels unsupported and very sloppy.

> Thus, the licensee pays a price to use the library. It is not a price paid > with money. [..] I could be missing something, but I have never seen any > other software license use such a condition and also claim to be an open > source license.

This just isn't thinking creatively. The GPL also requires a "price to be paid, but not with money" \-- you give up your right to keep changes you make secret (if you distribute them). Yet no-one seriously argues that the GPL isn't an open source license.

If there is something about giving up the right to file patent lawsuits that is totally different to giving up the right to keep your changes secret, the article doesn't say what that difference is. Giving up the right to keep your changes secret is surely _more_ stringent than giving up your right to file patent infringement lawsuits against one company. Why, then, should the latter be a dealbreaker for an open source license?

<comment><USER34> I think the argument is that the grant is asymmetric. GPL is "I open up, you open up". The retaliation clause Facebook uses is "you don't get to sue us, but we may sue you".

<comment><USER66> That's an interesting argument! (But the article didn't make it..)

Couldn't you argue that the GPL says "you don't get to keep your changes private, but I do", and so is asymmetric too? It seems normal to me for the rightsholder to retain more rights than the grantee.

<comment><USER34> You can keep GPL changes private if you don't publish it, and the same applies to the original author. If you feed back changes, you're mutually bound.

But the problem with Facebook's license is not the copyright, it's the patent grant.

</comment></comment></comment></comment><comment><USER67> React.js is basically licensed so that you cannot make anything that can compete with facebook corporation.

Example:

1\. You create something similar to Instagram using React.

2\. It gets popular

3\. Facebook sues you and takes all your reacts and reducers

<comment><USER68> Actually I see it as

3\. You can't sue Facebook because your app is similar to Instagram

<comment><USER69> Is such a clause actually enforceable? Has this been tested in a court of law? Just curious.

<comment><USER70> Well, the clause isn't "you can't sue", it's "you have to stop using React if you sue".

<comment><USER69> But what if you don't stop using it?

<comment><USER71> You can be sued by Facebook for infringing their license.

<comment><USER69> Which brings us back to my original question ;)</comment></comment></comment></comment></comment></comment></comment>


Neurons grow into semiconductor tubes: future intelligent chips? - <AUTHOR> http://www.braincubix.com/

<comment><USER2> No, the implications of this do not include "intelligent chips". Neurons aren't "smarter" than something we can currently create digitally, and if anything they transmit information more slowly.

The primary use of technology like this? Better brain implants (especially interesting considering the reported increased attractions neurons had for the tubes; this is one of the major problems in brain implants right now).

<comment><USER3> Amen to both points.

</comment></comment><comment><USER4> This should link directly to the page on braincubix.com, [http://www.braincubix.com/post/5044460599/neurons-grow- into-...](http://www.braincubix.com/post/5044460599/neurons-grow-into- semiconductor-tubes-future)

Second, this is the link to the original journal article [http://pubs.acs.org/doi/abs/10.1021/nn103618d?journalCode=an...](http://pubs.acs.org/doi/abs/10.1021/nn103618d?journalCode=ancac3)

</comment><comment><USER5> seriously?</comment>


Decreasing human body temperature in the U.S. since the industrial revolution - <AUTHOR> https://elifesciences.org/articles/49555 <comment><USER2> Decreasing over time. The following example from Feynman's rightly extremely famous "Cargo Cult Science" lecture is extremely relevant. Now it may not be what is going on here at all, but that probably needs to be established somehow before deciding that some other alternative (eg instrumentation changes, everyone's actual temperature has changed rather than just its recording, whatever other theory).

And if you haven't seen it, it's fantastic. As is the whole lecture, 5 minutes you really won't regret.

"We have learned a lot from experience about how to handle some of the ways we fool ourselves. One example: Millikan measured the charge on an electron by an experiment with falling oil drops and got an answer which we now know not to be quite right. It's a little bit off, because he had the incorrect value for the viscosity of air. It's interesting to look at the history of measurements of the charge of the electron, after Millikan. If you plot them as a function of time, you find that one is a little bigger than Millikan's, and the next one's a little bit bigger than that, and the next one's a little bit bigger than that, until finally they settle down to a number which is higher.

Why didn't they discover that the new number was higher right away? It's a thing that scientists are ashamed of—this history—because it's apparent that people did things like this: When they got a number that was too high above Millikan's, they thought something must be wrong—and they would look for and find a reason why something might be wrong. When they got a number closer to Millikan's value they didn't look so hard. And so they eliminated the numbers that were too far off, and did other things like that." [1]

Needless to say the actual charge on an electron is very likely to have been constant over that period rather than trending steadily upward.

[1] [http://calteches.library.caltech.edu/51/2/CargoCult.htm](http://calteches.library.caltech.edu/51/2/CargoCult.htm)

<comment><USER3> Interestingly, here in Japan, I learned that they consider a lower body temperature normal. I always learned in France that the normal body temperature was 37.7C, some people say 37.3. Can be lower just after waking up.

For my Japanese wife, 37C means you may starting to get sick. you should be in the 36s.

Just an anecdote, but the normal temperature could vary among population, latitude, weather conditions...

<comment><USER4> Normal body temperature is 36.6°C (97.9°F) even in France, but can be up to 37°C sometimes or in some places. Temperature of 37.7°C is symptom of sickness.

[https://www.bmj.com/content/359/bmj.j5468](https://www.bmj.com/content/359/bmj.j5468)

Results:

In a diverse cohort of 35 488 patients (mean age 52.9 years, 64% women, 41% non-white race) with 243 506 temperature measurements, mean temperature was 36.6°C (95% range 35.7-37.3°C, 99% range 35.3-37.7°C). Several demographic factors were linked to individual level temperature, with older people the coolest (–0.021°C for every decade, P<0.001) and African-American women the hottest (versus white men: 0.052°C, P<0.001). Several comorbidities were linked to lower temperature (eg, hypothyroidism: –0.013°C, P=0.01) or higher temperature (eg, cancer: 0.020, P<0.001), as were physiological measurements (eg, body mass index: 0.002 per m/kg2, P<0.001). Overall, measured factors collectively explained only 8.2% of individual temperature variation. Despite this, unexplained temperature variation was a significant predictor of subsequent mortality: controlling for all measured factors, an increase of 0.149°C (1 SD of individual temperature in the data) was linked to 8.4% higher one year mortality (P=0.014).

<comment><USER3> I found something super interesting!

The EN and FR wikipedia state different values.

FR:

> On considère généralement que la température basale usuelle du corps humain > est de 37,0 °C, [...] Une température corporelle normale se situe entre 36,1 > °C et 37,8 °C

Baseline : 37C. Normal range, [36.1 - 37.8]

EN:

No baseline, provided,just a range:

> The normal human body temperature range is typically stated as 36.5–37.5 °C > (97.7–99.5 °F).

The French version explains that for a long time, until the 1980s, everybody assumed correct a study made in 1868 about the body temperature that found 37.0 - 37.5 to be the normal range in healthy adults.

It suggests that the declining prevalence of infections in the population may be the exaplanation of the lowering of the average body temperature.

After all, one of the main causes of rising temperature is an active immune system. Lower temperatures in the population are actually good news.

</comment></comment></comment></comment><comment><USER5> When we're discussing relatively small changes in temperature over very long periods of time, I wonder how confident we are in those measurements? I mean a very regular trend like this is a pretty strong signal that you're at least not overwhelmed by random noise, but: I find it very hard to believe that our ability to manufacture very precise and accurate thermometers has been so consistently good (measuring hundredths of degrees) for the order of decades. Am I wrong? I often wonder how much this impacts climate change studies as well. Ocean acidification just "feels" like much sounder science to me because the effects are so much more visible, but I'm not certain about our ability to measure pH so precisely for decades either.

<comment><USER6> Due to the way statistics work, you don't need to be able to measure hundredths of degree to detect a hundredth of degree average change.

Because the error will distribute around the true value, thus even with sampling errors you can still extract a signal, even a very weak one, if you have many samples.

<comment><USER7> It depends on the error. It could be that older thermometers were systematically biased.

<comment><USER6> Could be.

But surely we have some which survived, or can manufacture using methods of the time to check.

Also, physics was in a pretty good state at the time, at least regarding temperature/length measurement. Surely the scientists of the time measured the bias.

<comment><USER8> Measuring the bias would require knowing the true temperature.

</comment></comment></comment></comment></comment><comment><USER9> From the intro, why this is interesting:

> The question of whether mean body temperature is changing over time is not > merely a matter of idle curiosity. Human body temperature is a crude > surrogate for basal metabolic rate which, in turn, has been linked to both > longevity (higher metabolic rate, shorter life span) and body size (lower > metabolism, greater body mass).

<comment><USER10> > Human body temperature is a crude surrogate for basal metabolic rate

> higher metabolic rate, shorter life span

> lower metabolism, greater body mass

In other words, if you are a really, really skinny person (like myself), you would be looking at a statistically shorter lifespan, unless somehow your normal body temp is lower than average or you spot some other sign of decreased basal metabolic rate. Huh!

I had some intuition along those lines but thought it's false, and habitually viewed high metabolic rate as nothing but a "feature" until now.

I suppose, then, you might want to be aware of this if you have a young family—get life insurance, if you haven't already (and I also hope, if this research proves sound, insurers won't start taking it into account any time soon).

<comment><USER11> > if you are a really, really skinny person (like myself), you would be > looking at a statistically shorter lifespan, unless somehow your normal body > temp is lower than average or you spot some other sign of decreased basal > metabolic rate. Huh!

I think you are making the error of combining the "folk" understanding of high metabolism - that you are skinny, with the scientific understanding of high metabolism, which means you expend a lot of calories every day. It's more likely that you have calorically restricted yourself throughout your life to become skinny, which has longevity benefits, and it's also likely that very fat people burn a lot of calories every day - high metabolism, worse for longevity.

<comment><USER12> My fundamental question on calorie restriction is that women have been doing it for superficial reasons for quite a while, but women's superior life expectancy seems soley due to high risk behavior by men when they are young and middle age.

I've never seen anything testing that hypothesis.

<comment><USER13> There are actuary tables of average life expectancy given a base age. If you are a 70 yo female, you're expected to live 2 years more than a 70 yo male.

[https://www.ssa.gov/oact/STATS/table4c6.html](https://www.ssa.gov/oact/STATS/table4c6.html)

It's possible this difference is a legacy from riskier makes behavior in middle age. I can't think of a reasonable way to control for this though. Maybe look cross culturally to see if the effect is stable with respect to different male behavior norms?

<comment><USER14> > If you are a 70 yo female, you're expected to live 2 years more than a 70 yo > male.

The difference is still a year at 86, and doesn't fall to par until supercentenarians.

</comment></comment></comment></comment></comment></comment><comment><USER15> An interesting note: Trevor Hastie is an author on this paper. The crowd around here probably knows him best for books he co-wrote: The Elements of Statistical Learning (2001) and An Introduction to Statistical Learning (2013).

<comment><USER16> It's funny reading the comments in this thread from random internet people postulating that the authors have probably made some statistical mistake or overlooked something. Then you see Hastie in the author list. Nope, no methodological mistakes made here.

</comment></comment><comment><USER17> This is interesting, I didn't know 37° is considered normal in the US. In Ukraine where I grew up as a child (and I imagine also other post-USSR countries), 36.6° was always taught to be the norm, and 37° typically considered an onsetting light fever. However, the typical measurement was always armpit and not oral - maybe that explains the difference.

<comment><USER18> Interesting. I live in canada, and I never measure 37 or above unless I have at the least a cold or other sickness.

But when at the doctor nurses will always mention something like 37.2 as not indicating sickness.

My normal temp is 36.4-36.6ish.

<comment><USER19> > But when at the doctor nurses will always mention something like 37.2 as not > indicating sickness.

Note though that they may not be wrong, even if you're sick and you know it from that temperature alone: 'indicating' is a term of art.

More than just 'based on this it does/doesn't seem to be the case that' it means that a specific (guideline-given, perhaps regulated) set of criteria have or haven't been met that tell them whether a certain procedure or whatever should be ordered.

It doesn't mean they can't also listen to what you're saying, and proceed as though it was indicated , making a judgement on that basis.

</comment></comment></comment><comment><USER20> Most likely due to most people lifestyle:

\- diet (way too poor in vegetables and fruits which are amazing sources of nutrients of all sorts, (note: nutrients degrade really fast with temperature/cooking) that facilitate cell functions, blood circulation, etc..)

\- Over-heating and 'over-clothing': these artificial heating is making our own natural heating less efficient (people over-heat in winter for example, it's possible to spend the whole evening and night at 15°C, I live in the south of France, I don't even heat my apartment, and casually even open windows at night in winter)

\- Lack of exercise, sun exposure, and quality sleep

</comment><comment><USER21> The article makes, in the discussion section, an hypothesis related to more time spent in thermally neutral areas as well as better heating and whatnot due to insulation and AC. Is it possible to formulate a similar thesis for overall higher ambient temperature linked to global warming?

<comment> semi-extrinsic That's much smaller though - probably average indoor temperature has gone up ten degrees easily.

</comment></comment><comment><USER22> I have to wonder what effect changes in clothing have had over the decades. The steady trend has been for people to wear less and less clothing since the 1800s, right? But the word "clothing" doesn't appear anywhere in the paper.

I also feel like Amish people living a very old-fashioned lifestyle might make an interesting control group.

</comment><comment><USER23> On a related topic, one thing unexpected thing that I learned after I had my thyroid removed is that there is a LOT of pseudoscience online about body temperature. In particular, there are plenty of quacks that are eager to diagnose hypothyroidism if the body temperature comes back as less than 37°C .

<comment><USER24> Why do you say that's pseudoscience?

*edit: People are downvoting this without explaining? C'mon.

[https://www.ncbi.nlm.nih.gov/pubmed/29237616](https://www.ncbi.nlm.nih.gov/pubmed/29237616)

<comment><USER23> It is used as an excuse by quack doctors (including naturopaths and "functional medicine" practitioners) to diagnose people with hypothyroidism even if all the blood tests come back normal. Here is a good summary: [https://hormonesdemystified.com/basal-body-temperature- and-y...](https://hormonesdemystified.com/basal-body-temperature-and-your- thyroid-why-i-dont-care-and-neither-should-you)

As for the paper you linked, a correlation of -0.013 degrees centigrade is too small to be useful as a diagnostic tool.

<comment><USER24> Good to know

</comment></comment></comment></comment><comment><USER25> This study suggests that from DNA evidence that natural human lifespan is _38_ years old, the same age that was the life expectancy during Wunderlich's 1851 survey.

[https://elifesciences.org/articles/49555](https://elifesciences.org/articles/49555)

Additionally, our heating systems were vastly less sophisticated, and we were outdoors more.

Together I think that these suggest that we get a sort of genetic gift of our bodies in our prime, but the growth program kind of peters out in our late 30's. After that it's a genetic maintenance program, with which, in concert with modern society, we have a good chance to keep the machine going for quite a long time.

<comment><USER26> The 38 years figure is misleading since it's skewed by high infant mortality rates. If you made it to 15 then for most of human history you'd probably live into your 50s or 60s.

<comment><USER25> yeah, I think you're definitely right about this, this skews the picture to your 50's or 60's for sure -- I think that like, human growth hormone levels also bear this out.

</comment></comment></comment><comment><USER27> _tl;dr_ speculated causes: reduced inflammation; home heating/cooling

I would have thought more sedentary lifestyle would have decreased resting metabolic rate, but they didn't mention that one.

<comment><USER28> I don't see them discussing the definition of "resting metabolic rate" in this paper. I don't know how long it takes the body to reach the "resting metabolic rate" though I imagine it varies depending on quantity and intensity of physical activity.

What I'm getting at is that people are more likely to drive to the doctor than they were in the past, which means they actually were likely at a truly resting metabolic rate when arriving at the doctor's office. While in the past, it's more likely people might have walked (or ridden a horse) a mile or more to the office, which I imagine would result in the "resting rate" to often not actually be a resting rate but be somewhat elevated.

</comment></comment><comment><USER12> Humans are less active and probably have a reduced basal metabolic rate, which is where the heat comes from.

That seems the obvious explanation, moreso that disease-related inflammation.

<comment><USER29> This makes a lot of sense to me.

</comment></comment><comment><USER30> Because medicine has been more and more careful about inflammatory responses, I propose that the reduction in inflammation (internal and minor) has been a co-factor.

</comment><comment><USER31> Huh. All my life I knew the rule-of-thumb value of 36.6°C, and I always assumed 37°C is just a crude rounded-up value of that.

</comment><comment><USER32> What if overweight people run cooler as well?

</comment><comment><USER33> In Soviet Union it has always been 36.6

</comment><comment><USER34> For those unaware -- men's sperm count has gone down 3% a year since we've started measuring.

I see these two facts as potentially related and warranting significant investigation.

<comment><USER35> Not only that, but testosterone levels have been dropping in men for decades. Being that testosterone is essential to men's health and well-being, and they comprise 50% of people, you'd think society would care more about it.

[https://www.forbes.com/sites/neilhowe/2017/10/02/youre- not-t...](https://www.forbes.com/sites/neilhowe/2017/10/02/youre-not-the-man- your-father-was/)

[https://uk.reuters.com/article/health-testosterone-levels- dc...](https://uk.reuters.com/article/health-testosterone-levels-dc- idUKKIM16976320061101)

<comment><USER36> Last year I got my hormone levels checked for the first time (normal), and I'm going to continue to do so yearly to keep track. Given how important it is, it's really surprising to me that testosterone levels aren't part of regular health exams/bloodwork panels - I had to convince my doctor add it on.

<comment><USER37> Because the only real fix is giving the patient testosterone which has very real stroke risks.

<comment><USER38> Citation? If you are deficient in testosterone, replacing it is giving your body what it needs.

<comment><USER37> [https://en.wikipedia.org/wiki/Androgen_replacement_therapy#A...](https://en.wikipedia.org/wiki/Androgen_replacement_therapy#Adverse_effects)

<comment><USER38> There are also lots of conflicting studies like this: [https://www.ncbi.nlm.nih.gov/m/pubmed/26248567/](https://www.ncbi.nlm.nih.gov/m/pubmed/26248567/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER39> This might have to do with increasing BMI, though the direction of the causal relationship could go either, or both ways. I wonder if I can dig up a plot of average fat composition over a similar period of time. I don't know how recently we started getting fatter but I suspect it started slowly with the industrial revolution.

<comment><USER40> They controlled for height and weight in the study

</comment></comment><comment><USER41> I have a weird feeling this has to do with higher alcohol consumption in the older days. I wonder if there are many other heavy drinkers who have a high body temperature like myself.

<comment><USER42> Although alcohol carries a reputation for keeping people warm when its cold, it actually has the opposite effect and lowers body temp. But you know...if your gonna be cold, better to be a little colder and drunk than cold and sober.

<comment><USER43> Alcohol cools by widening the blood vessels in your skin and extremities. This makes you feel warmer, yet it lowers your overall average and core temperature. This is what makes alcohol in cold weather so dangerous: it really helps your cold fingers and makes you feel better, while actually making you worse off by wasting heat.

</comment></comment></comment><comment><USER44> Perhaps this can be partially explained by measurements becoming more precise over time?

<comment><USER45> The abstract, which is only 4 sentences long, explains that they considered this and dismissed it as unlikely.</comment></comment>


Java hashcode performance boost - <AUTHOR> http://mikemainguy.blogspot.com/2012/05/how-to-juice-your-java-performance.html

<comment><USER2> I agree that this approach (caching hashcodes for immutable objects) will probably save some calculation at the cost of increasing memory usage, as is usual for memoization techniques. Without any empirical measurements, though, this article isn't very useful. Compiler optimizations aside, the internals of the hashmap implementation may render this tweak moot.</comment>


How the Benzene Tree Polluted the World - <AUTHOR> https://www.theatlantic.com/science/archive/2017/10/benzene-tree-organic-compounds/530655/?single_page=true <comment><USER2> The pictures of the Budweiser & Spam cans at nearly 4000 and 5000 meters depth respectively are astonishing: [http://oceanexplorer.noaa.gov/okeanos/explorations/ex1605/lo...](http://oceanexplorer.noaa.gov/okeanos/explorations/ex1605/logs/apr22/welcome.html)

<comment><USER3> looking at the image, i mentally interposed the can upon detailed photo of Saturn rings. We'll be there one day...

<comment><USER4> Thing is, none of this becomes definitively cool for at least another 100 million years after we go extinct, when the universe resumes an era of prehistory prior to the next intelligent life form to emerging from some primordial soup.

Worse still, if that inter-historic era never occurs due to the persistent presence of intelligent machines.

At that point, all bets are off, as to whether even remnants of our pollution might remain, in the face of pervasive systems engineered to keep ecosystems free of the detritus of human civilization, and automatically recuse themselves from pristine areas that require no further stewardship.

</comment></comment></comment><comment><USER5> Not trying to downplay the issue because their are serious implications of PCB exposure, but the article just says "PCBs were detected" in marine life. The real question is how much?

As a former chemist, we have a ridiculous ability to detect chemicals. It's not unusual to have lower detection limits in the parts per trillion or lower. For reference 1 ppt is 1 mg of chemical in 1000 metric tons of water (or a cube of water 10 m on each edge). We can detect it, but the likelihood is that it doesn't have an impact.

Looking at the paper quoted in the article, PCB concentration was ~100 ppb of dry weight, which would be less looking at wet weight (the nature state of the organisms).

<comment><USER6> I just want to say it really depends on the chemical and location in the food chain. Something that's stable and bioaccumulates can have meaningful impact on top preditors even with extremely low initial concentrations.

Especially if it is unusually potent. To use a famous example the LD 50 on VX is ~7 µg/kg. Now, picture something like that that also bioaccumulates.

</comment></comment><comment><USER7> _Industry develops and retracts chemical classes in waves without seeming to absorb the larger lesson._

I've studied environmental and industrial chemistry and I'm not sure exactly what larger lesson the author thinks was available for the taking but left unabsorbed by industry. The highly halogenated structures that dominate persistent organic pollutants (it's the multiple fluorine/chlorine/bromine atoms that cause persistence, not the benzene ring) were largely developed in an effort to improve human welfare. PCBs were not flammable, so safer for use in hot transformers than earlier plain-hydrocarbon dielectric fluids. Polybrominated diphenyl ethers show up in furniture and clothing because they are effective flame retardants. They became ubiquitous in direct service to human safety. DDT seemed, initially, like a miraculous savior of human health and crops from harm by insects.

After many real-world cautionary examples, the availability of better bench screening assays, and the development of quantitative structure-activity relationship models, today we can have a pretty good idea of whether a compound will be an endocrine-disrupting persistent organic pollutant _before_ it becomes a high volume industrial product. None of these lessons or tools were available in the first half of the 20th century when these chemicals entered the mainstream of industry. Animal tests were around, of course, but the insidious thing about a lot of POPs is that they _don 't_ have obvious, acute health consequences. The LD50 may be quite high. If you're just trying to figure out "will this kill exposed workers/consumers," the assays won't reveal that (e.g.) long term thyroid function suffers in exposed mammals, or see endocrine effects that interfere with sexual organ development in young animals. You don't know what you don't know.

All that said, I certainly _can and do_ criticize the modern chemical industry for foot-dragging, delaying tactics deployed against regulating chemicals that have demonstrated obvious ill effects in animals, or that are so structurally similar to other POPs that they really shouldn't maintain grandfathered approvals. It took until _last year_ for the EPA to regulate perfluorooctanoic acid in drinking water, whose formula alone should ring chemists' alarm bells with regard to bioaccumulation and persistence: [https://en.wikipedia.org/wiki/Perfluorooctanoic_acid](https://en.wikipedia.org/wiki/Perfluorooctanoic_acid)

<comment><USER8> People go all ape s __t over the potential for radioactive waste contamination, but I think its only a matter of time before we cover the planet in something that really messes with higher life forms in a massively negative way. This may have already happened, and we don 't even know it.

Its going to be a case of "hey look a new Plasticizer/dye/whatever, is awesome lets use it in all the new $ConsumerProducts", followed by the realization later after we have basically lets it contaminate every cubic inch of water/soil/air that it damages some fundamental aspect of our biology and is the cause of massive cancer rates/birth defects/IQ loss/whatever.

So, the question is, do you think our knowledge of mammal biochemistry is sufficient to have models that can predict every form of possible damage?

Put another way, is endocrine disruption the only pathway to serious long term biological damage?

Do we even know enough to answer those questions accurately?

<comment><USER9> > Do we even know enough to answer those questions accurately?

No, we don't.

And that's why using persistent organics is dangerous.

</comment></comment></comment><comment><USER10> There's a lake not far from me in Raleigh, NC that I often run past. The lake is used for recreation. It's also an EPA Superfund site because a company long since out of business, Ward Transformers, saw fit to dispose of its polutants right into a ditch behind the plant. The chemicals ran off into the lake and streams for miles. All the nearby waterways warn not to eat the fish caught therein.

At one point, a contractor hired by the company to dispose of the chemicals was caught spraying them along rural roadsides.

[http://sph.unc.edu/superfund-pages/srpresources/ward- transfo...](http://sph.unc.edu/superfund-pages/srpresources/ward-transformer- superfund-site-resources/)

[https://sph.unc.edu/files/2015/08/SRP_Soil-Still- Toxic-25-ye...](https://sph.unc.edu/files/2015/08/SRP_Soil-Still- Toxic-25-years-later.pdf)

</comment><comment><USER11> "How PCBs reached the Mariana is still under investigation"

Well in Western Australia PCB's by the truckload in 44 Gallon Drums were dumped into the ocean and left to rust away off South Fremantle for many many decades, so this does not surprise me if this was happening all over the world.

</comment><comment><USER12> It's a bit odd that they used the PCB acronym to describe these chemicals. It leads to sentences like:

>Soon PCBs were added to paints, caulks, plastics, even floor finishes and dish detergents.

<comment><USER13> It's an old abbreviation in the chemical world.

For HN audience, the most recognizable older source that uses it a lot might be Neal Stephenson's _Zodiac_ from 1988 :), but the chemicals are much older than that.

<comment><USER14> It is well known in the high voltage world, many old (it was banned around 1985) transformers and capacitors were filled with it.

<comment><USER15> Yep, and the disposal method for those old transformers was far too often "throw it in the woods down the street".

Every so often the local news will do a story when someone finds another pile of rusty and leaking transformers sitting on a lot behind a daycare or something.

</comment></comment></comment></comment><comment><USER16> If stories like this interest you, I recommend the book Toms River by Dan Fagin about a major chemical factory in Toms River, NJ.

</comment><comment><USER17> Anyone who finds this story interesting should read _Zodiac_ by Neal Stephenson.

</comment><comment><USER18> It seems almost inconceivable that a long-form humanistic article like this would omit the fact that Kekulé discovered the ring structure of benzene _in a dream about the ouroboros_ :

[https://nevalalee.wordpress.com/2011/05/29/friedrich- august-...](https://nevalalee.wordpress.com/2011/05/29/friedrich-august- kekule-on-an-unusual-dream/)

Surely that's a guaranteed crowd-pleaser!

</comment><comment><USER19> Is it worth the hassle to disable ad-blockers?

<comment><USER20> I didn't see the ad-blocker-blocker loading this URL in Brave. Also, often blocking both ads & JS for a site blocks the ad-blocker-blocker.

<comment><USER21> Can confirm, just disabling JS gets around almost all anti-adblock, as well as speeding up pageload by 10-20x and removing obnoxious stuff from the page.

<comment><USER22> The really bad blocker blockers use noscript <meta refresh> headers, which most JavaScript blockers don't do anything to. Weirdly, I've only ever seen those on local newspaper websites. They just force redirect to a nastygram if you aren't running JavaScript.</comment></comment></comment></comment>


Hashlife - <AUTHOR> https://en.wikipedia.org/wiki/Hashlife <comment><USER2> The reason why this is interesting to me, game of life is like my mental shortcut to the idea that there are simple rules that lead to computations that can't be effectively shortcut.

Turns out that this one can, kinda.

<comment><USER3> Simple rules also often lead to simple outcomes that happen to be optimizable, and those simple outcomes are often the most likely... until someone or some process accidentally discovers complexity and it takes over the game, as happens when a god takes advantage of the turing completeness capable in that physics or would naturally happen if true life--not just a replicator, but a higher level replicating entity capable of evolution--took hold in a world run by this ruleset... so please do not discount your original conclusion as it is entirely true.</comment></comment>


Tell HN: YC Hackathon invitation emails are out - <AUTHOR>

<comment><USER2> What were some critertion used? I got a reject :(

<comment><USER3> Same here, would be good to know.</comment></comment>


Ask HN: What are your Black Friday money saving hacks? - <AUTHOR> <comment><USER2> Not shopping on Black Friday at all.</comment>


Two Ways Google Is Trying To Juice AdSense: Ad-Only Search Boxes And Syndication Pages - <AUTHOR> http://www.techcrunch.com/2008/10/19/two-ways-google-is-trying-to-juice-adsense-ad-only-search-boxes-and-syndication-pages/

<comment><USER2> Ok this deserves the top page: an article about things years old on TC and the author is claiming this are signs of recent strategical changes. This is really high quality stuff...

</comment><comment><USER3> Today I typed into Google, L.A. to San Diego

A few months ago when I did the same thing Google gave a link to the map/directions/distance.. today it gave me an ad "Limo from L.A. to San Diego," next to the map without the directions.

Way to put the dollar ahead of the user experience...thats how you got to where you are. Simple UI that provides instant gratification, but today and hopefully only today Google was MySpace!

</comment><comment><USER4> Who cares. Mostly retards and IE users click on ads. That's why I love wordpress's strategy so much (only show ads to IE users).

</comment><comment><USER5> Google needs to figure out display. Really needs to. or someone else will.

</comment><comment><USER5> Google needs to figure out display. Really needs to. or someone else will.

</comment><comment><USER6> Neither of these are new, they've been doing this for months if not years.</comment>