olov's comments

Live stream recording here: https://youtu.be/Fx304EfqtMo?t=2468

Live stream recording here: https://youtu.be/Fx304EfqtMo?t=395

I haven't been able to see the comments so I can't give feedback on that, but you should give proper credits to the book's author, Marijn Haverbeke and respect his choice of license, http://creativecommons.org/licenses/by-nc/3.0/ (summary) and http://creativecommons.org/licenses/by-nc/3.0/legalcode (full license).

Thanks - I somehow managed not to look at that (saw it now after Twitter feedback). I can't edit my earlier comments so I'll just amend here instead: There are open source lawyers who consider simple permissive licenses such as Modified BSD and MIT to have an implicit patent grant. The first public discussion I found on this after a quick search is at http://lwn.net/Articles/389016/ - would love to see more and earlier.

If you the licensee also consider Modified BSD to have an implicit patent grant then the React patent grant is much worse for you than if it hadn't existed.

Guess I'm less less-informed now.

Thanks for being specific. I agree that Facebook's termination clause is crafted to benefit Facebook more than should they have used similar language to Google's (or APL2.0). A less defensive patent grant would have been more generous.

But I'm not sure I agree with your conclusion though.

Scenario one: MYCOMP uses React in a product, decides to sue FB because FB uses the term "It's complicated" which MYCOMP was granted a patent for by the US patent office (the phrase was translated into a dual-ROT13-machine for the purpose of the patent application). MYCOMP had tried to get FB to pay them a reasonable license fee prior to suing but Facebook neglected. Now MYCOMP does not have a patent grant for their use of React any longer but isn't that then ~similar to as if React didn't have any patent grant to begin with (from a litigation perspective) - like most MIT and BSD licensed software we use? Had I been with BIGCORP I'd have asked the legal folks or our favorite patent attorney but now I'm solo so I'm throwing out the question here for further discussion.

Scenario two: FB sues UCOMP (who uses React in one of their products) for patent infringement of FB's "Send message from client to server" patent (nicely masqueraded in the patent application). UCOMP decides to counter-sue and we have a situation similar to scenario one.

Now, I don't know what makes things "better" for you but from the perspective of most licensees it is probably legally better to have a conditional patent grant than none at all, most of the time. But it will vary depending on, for example, the licensors (their) and licensees (your) patent portfolios and intention to enforce those aggressively as well as your strategies of defense. There's a huge difference between a company such as, say Oracle and Facebook, here.

Granting patents in the context of permissively licensed open source is a generous act and making the grant conditional is a way of not giving up your ability to form the strongest possible defense when you're brought into patent litigation. If you have been following along the recent years events (where is that patent apocalypse, anyone?) then it should be no surprise why companies need to do that.

Conditional patent grants are not new. Apache License v2.0 has a conditional patent grant [http://www.apache.org/licenses/LICENSE-2.0]. Google added a conditional patent grant to WebM, complementing its Modified BSD license [http://www.webmproject.org/license/additional/]. Google's Dart project is licensed under Modified BSD and has a.. you guessed it - conditional patent grant [https://code.google.com/p/dart/source/browse/trunk/dart/PATE...].

"much-discussed" by "less-informed" I'd say.

There is nothing sad about React PATENTS file.

1. React source code is licensed under the Modified BSD license.

2. React also comes with a conditional patent grant. Here "conditional" means that the patent grant may terminate under some conditions. It does not terminate 1.

Most BSD and MIT-licensed software you use comes without a patent grant at all.

Still sad?

I don't understand your claim about redundancy. Amazon says that Glacier "is designed to provide average annual durability of 99.999999999% for an archive", https://aws.amazon.com/glacier/details/#durability. This seems to be the same as for S3 objects. Furthermore, they say that "the service redundantly stores data in multiple facilities and on multiple devices within each facility".

So multiple facilities and multiple devices on the same facility (I guess that means at minimum 4 copies), and a calculated annual durability. Not so secret?

What are Backblaze's (and Crashplan's) redundancy policies?

You managed to cover a lot in those 40 minutes. Well done!

I beg to disagree. The credit card is "something you know" just as much as "something you have", because when used on the web it is just a (copyable) 23 digit number. Whether you remember the number or look it up in your wallet is no different than whether you remember your password or store it on a post-it.

Other things "you have" in popular 2FA solutions are quite different, for instance your mobile phone number identity (for SMS) or your Google Authenticator.

I don't know if it's really fair to call Verified by Visa two-factor authentication as your card number is just another string (that can be replicated). With Verified by Visa you go from one to two "passwords".

Disable SSL3.0 in golang ListenAndServeTLS: https://gist.github.com/olov/eb60ab878eb73a7c5e22

Hmm. There are no open bugs for that on the gulp-ng-annotate or browserify-ngannotate repos. https://github.com/Kagami/gulp-ng-annotate/issues and https://github.com/omsmith/browserify-ngannotate/issues

Feel free to open issues and I'm sure it will be addressed.

ng-annotate itself just produces output for input (stdin/stdout or via files) so it does not at all have any trouble participating in a "complex build environment".

it can certainly not support everything, partly because of limitations imposed by static analysis, buy you may be surprised with what it can handle.

Also: For situations where you don't know whether ng-annotate will detect a form or not (assuming you already use ng-annotate for your project), you can use explicitly use /* @ngInject */ or ngInject() to avoid stuttering the array yourself.

That occasionally happens when you do things in non-standard ways, although ng-annotate has become quite smart lately and can now follow references and more. Did you use the latest version (also feel free to open an issue)? ng-strict-di in AngularJS 1.3 will greatly improve the error messages for these situations.

"Rare" is the key here, thanks. An AFR of 3.2% is already a pretty damn long MTBF. Makes sense now!

Ok, after converting to MTBF the numbers make more sense: An AFR of 0.9% means a MTBF of 968947 hours (111 years). An AFR of 3.2% means a MTBF of 269346 hours (31 years).

I guess an MTBF of 31 years is plenty for your needs. Thanks again for sharing the data.

The AFR is 2.3 percentage points less (0.9% vs 3.2%), which in this case means that a single unit of the inferior brand is 3.5 times more likely to die during a full year of use. I'd love to see their calculations that justifies buying non-Hitachi drives.

If I'm not reading it wrong then your data says that the Hitachi drives have half the Annual Failure Rate, or less, than the others (in your setup). Not sure what this means in MTBF but the Hitachi's sure seem to be worth a whole lot more, certainly 10, 20 or 30 percent more - no?

"If the price were right, we would be buying nothing but Hitachi drives."

I don't understand why they don't. Are the Hitachi drives really that much more expensive so that it doesn't justify their vastly longer lifespan? Even if they can get "free" replacement disks during the warranty period, that has a cost for them. And they mentioned that some replacement disks die even faster.

I'm sure Backblaze has crunched all these numbers - would love to see them. BTW thanks for sharing this data!