2,803 karma · joined July 22, 2012
ISO/IEC and ITU have had a common patent policy since at least 2006. Here is their "Patent Statement and Licensing Declaration" form: https://www.itu.int/dms_pub/itu-t/oth/04/04/T04040000020004P...
On page 3, where the space for entering patent numbers is, it says they are "desired but not required for options 1 [royalty-free] and 2 [FRAND]; required in ITU for option 3 [refusal to commit to either of those licensing terms]". ISO actually allows you to claim you have patents on a standard, refuse to license them to anyone at any price, and not even tell anyone what the patents are, much less which part of the standard they cover. This has happened to at least one standard that was attempting to be royalty-free.
In general, you can assume the answer to the question, "Does the proponent of this technology have patents covering it?" is yes, for the reasons I outlined in the GP. So in practice the above disclosures provide nearly zero information. They don't help you evaluate alternative designs, because you don't know what you need to change to avoid the patents. You also don't know when one party might have patents on a contribution made by a different party [1]. The disclosure is at the level of the standard as a whole, and not by individual feature.
The disclosures are also not very specific about the actual licensing terms. I've had an expert lawyer who made her career on dealing with patent licensing tell me with a straight face that she had no idea what FRAND means. In some industries, it is common practice to require someone to sign an NDA before you will even tell them what your supposedly "non-discriminatory" terms are.
The actual licensing terms are negotiated well after the standard is complete, by which point it is too late to solve problems by excluding technology.
[1] This is quite common. People read the contributions of others and rush to file something based on the direction they think it is going. That ensures they have patents on the standard regardless of whether or not any of their own contributions make it in.
a) The people making the standard work for the companies filing the patents. They are highly incentivized to make their own patents required, and
b) There's all sorts of potential legal liability associated with just knowing about patents, much less telling anyone else or writing that knowledge down.
As a result, you get things like the ISO and ITU IPR policies which profess to make the standardization process "patent blind". That is, so long as you agree to license your patents under FRAND terms, you can participate, and no one is allowed to exclude your technology solely on the basis of your patents.
This results in maximally patented standards. Even if you're not interested in seeking rent from other standards users, lots of other people contributing to the standard are. So you're forced to file patents just to minimize the amount you have to pay to use the technology you yourself helped create.
That's why you see things like the HEVC mess, where four years after the standard was completed, no one knows if it's even possible to license all of the patents required, nor how much it would cost if you could.
You've got this backwards. The compilers "knows" the pointer is non-null because you dereferenced it, and dereferencing null would have been undefined behavior. That's what allows the compiler to assume that didn't happen.
There are many operations which will produce undefined behavior for some inputs (e.g., every pointer dereference, every signed integer arithmetic operation). Figuring out if it is possible for a program to encounter such inputs at runtime is equivalent to the halting problem.
This is why any attempt to craft a -Wundefined-behavior that works on non-trivial programs is doomed to failure. It may be possible to prove a program will definitely invoke undefined behavior in some useful subset of cases. Compilers already do this in some of them, even. But those cases (and many more, besides) would also be caught with ubsan and a unit test.
I tried running claws-mail on my old N900. Just opening my basic IMAP inbox with 20,000 messages in it exhausted the memory of the device. I have some folders with 200,000 messages. This was a while ago, so things may have improved, since.
The only client I've ever successfully run on such low-memory systems is webmail, or something like the Android mail client, which simply doesn't bother to look at more than a few hundred messages. The UX in both cases is abysmal, but they provide some functionality, which is a step up.
I may not be a typical e-mail user.
Having an already-existing contributor sign up for GSoC actually backfired on us. He had to come up with a "project" rather than the minor, drive-by contributions he'd been making (a project which he probably wasn't that excited about, to be honest). He then got behind and didn't finish, and then I guess was embarrassed, as we never heard from him again. So we lost a useful contributor.
During the exam, in addition to the expected technical questions, I was asked things like, "What lab did this work come out of? Who runs that lab?"
In other words, "Do you understand the political and funding environment in which you're going to be operating if you continue working in this field?" Fortunately, I had been to a few conferences and met some of these people (also not an accident on the part of my professors), so I knew the answers to these questions. But the lesson stuck.
You can view a sample license agreement, which does not mention such a cap, here: https://www.sec.gov/Archives/edgar/data/1114084/000101287003... Annual caps are essential for anyone whose business model involves giving away software for free on the internet (even an existing user downloading a new version triggers another royalty).
You may also notice that that agreement charges royalties for products made or distributed in "Non-Patent Countries", including those that purport not to have software patents. This is pretty standard. Essentially, if you'd like to sell your product in the US, you have to pay royalties on all units you sell, anywhere in the world.
+------
| 1
| 2
| 1 2 M
If you know there are three mines here, including the marked one, this is either +------
| M 1
| M 2
| 1 2 M
or +------
| M 1
| M 2
| 1 2 M
There's no way to ever get more information to resolve the ambiguity without guessing, and the mine probability in every square is 50%. This (or simple variants) is the most common late-game failure case. Similar symmetries can also occur on edges, and (though more rarely) even in the middle of the field.If you assume that you have knowledge of the 5 outside squares of a 3x3 corner (and any neighbors outside of that 3x3 corner) and that you know how many mines are left, you won't be able to fill in the rest without guessing 4.14% of the time on an Expert board. The most common failures are either three three-mine cases like the one illustrated here (0.440% likelihood each) or one of 16 four-mine cases (0.115% likelihood each). Given that there are four corners on the board, that sends your failure rate to at least 15.572% (actually higher, because you don't always know how many mines are left in one corner without clearing the other three).
If you want to fail fast, figure out if you have symmetry in the corners first.
Humans are loss-sensitive.
When Coca-Cola did blind taste tests for New Coke, it was overwhelmingly preferred. When they told people which was which, the preference for New Coke increased. Instead, when they removed Coca-Cola Classic from the shelves, people clamored for it back. People want the thing they cannot have. Scarcity creates desire.
To some, this is a simple engineering trade-off. You can't have sandboxing, tab isolation, and responsiveness improvements with XUL add-ons in any kind of feasible or sustainable way. You can estimate how many people use add-ons that can't (or won't) be ported to Web Extensions, how many people would benefit from the proposed improvements, what the relative changes in user adoption are likely to be for each, and make a call that gives the best result for the whole Firefox population.
But that won't stop the people who are feeling the loss from being vocal about it, nor others who don't even use those add-ons attaching value to the thing they can no longer have, and resent that it's being taken away.
To reverse course now would fail the other way: if you tell people you're going to hold off on full e10s deployment and the security and responsiveness improvements that will come with it to allow XUL add-ons to remain a while longer, they'll be upset that you've taken away the improvements you promised.
Both times the conversation will only be about one side of the equation. No amount of marketing will fix that. Just ask Coca-Cola.
Yes, tax-advantaged accounts are a different question, but Berkshire can't pay a dividend to just "the people who need money in a tax-advantaged account". If you want a smaller impact from fees, make fewer, larger transactions.
It's not like this requires particularly large sums. At 7 shares per transaction you're already under the industry average stock index fund expense ratio (0.76%), and unlike those funds, that's a cost that's incurred once on just the shares you sell, not annually on your whole investment. People pay higher (relative) fees to withdraw cash from an ATM.
I worked on Opus, which bottoms out at around 6000 b/s. A typical IP+UDP+RTP packet has 40 bytes of headers, which with 40 ms frames is 8000 b/s of overhead. Cell networks will use header compression to reduce that, but even so. 8000 b/s is almost eleven and a half 700C codec2 streams.
codec2 is just in another league. It's seriously impressive work.
I've seen the legal status listed on http://portal.uspto.gov/pair/PublicPair be literally years out of date, and I don't know of any way to ask the US PTO if a given patent is expired. I was hoping this site had figured out something I didn't know.
When it matters, make sure to consult your lawyer.
TLS 1.3 also supports 0-RTT connections for servers the client has connected to before using a static "pre-shared key". There is some additional vulnerability to replay attacks (newly introduced with 0-RTT) and loss of forward secrecy (the same as 1-RTT session resumption in TLS 1.2) of the application data sent in the initial ClientHello. The rest of the data sent in the connection has the full set of TLS security guarantees. The pre-shared key approach has less overhead for servers and a simpler synchronization problem for load-balancers than the session IDs and session cookies of TLS 1.2.
See, e.g., https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/ for more.
What, like the largest US mobile carrier injecting supercookie tracking headers into every unencrypted HTTP request? [1]
Yeah, I guess that's only 144 million people.
Then there is the whole MUTANT BROTH program, which maintains a database of billions of intercepted cookies, and can be correlated with other traffic to identify particular engineers behind a corporate firewall for targeting and exploitation, as was done with Belgacom [1]. To thwart such an attack requires encrypting any request that contains a cookie (or, conversely, never accepting a cookie from an unencrypted site).
The problem is that it's really hard to make judgments about what's "security sensitive" for someone else.
[1] https://theintercept.com/2014/12/13/belgacom-hack-gchq-insid...
Yes. It's called "Opus".
This is really the biggest one. Google has been using low-resolution test material for VP10, and back in September [1] were claiming only a 10% reduction over VP9 on CIF resolution material (352x288). Neither VP9 nor HEVC get anywhere close to their claimed 50% improvement over H.264 on this kind of material (both save around 20%).
So seeing 7...8% reductions at similar resolutions just from a better encoder is pretty significant. It would be great to see how it scales beyond 720p.
[1] https://www.youtube.com/watch?v=gkz1ZvejmEc&list=PLQLpBN3oI7... (sorry for the YouTube link, I couldn't find slides).
Maybe that just means I don't write very interesting papers.
That's the reason for the asymmetry in the second diagram that was not present in the first.
[1] https://news.ycombinator.com/user?id=rayiner
[2] https://en.wikipedia.org/wiki/Alayne_Fleischmann
[3] https://en.wikipedia.org/wiki/Richard_M._Bowen_III
[4] https://www.nolo.com/legal-encyclopedia/false-affidavits-for...