derf_

You may dimly recall from your undergraduate Macro courses a relationship between unemployment and inflation called the Phillips Curve [0], which is used to evaluate one of the "dual mandates" the Fed tries to fulfill with its interest rate setting policy.

The problem, of course, is that there is evidence from the Fed's own research that suggests that the Phillips Curve is balderdash [1]. That doesn't stop central banks (including the Fed) from pretending it's still true, though.

[0] https://en.wikipedia.org/wiki/Phillips_curve

[1] https://www.philadelphiafed.org/-/media/research-and-data/pu...

[1] https://web.archive.org/web/20160404051240/http://people.moz...

It is also used for digital cinema distribution. It was chosen for that role specifically because it was not in widespread use.

To be fair, the same was true of the original JPEG when it was released. JPEG also has an optional arithmetic coder based on IBM's Q-coder, which was heavily patented at the time. To this day, no one implements that, even though it does improve the compression and even though IBM's patents have long expired.

It has been broken for a long time and was eventually removed: https://bugzilla.mozilla.org/show_bug.cgi?id=606655

1) They have a fairly limited catalog (contrast with the constant ingestion of new content by Youtube, for example)

2) The cheapest way for them to ensure they have sufficient capacity to handle peak loads leaves them with a lot of extra compute during non-peak times. That excess compute is essentially free.

[6] https://archive.is/

> Something bad could happen to my pages in transit from a server to the user's web browser.

This already happens. Verizon injects tracking cookies into unencrypted requests [1]. Hotels inject advertising on top of the existing advertising [personal experience]. They will do it when I read your blog archive from 2001. They will inject arbitrary JavaScript that records my every keystroke and mouse movement [2]. State actors will use persistent surveillance of all unencrypted cookies to pierce firewalls and target individual engineers in charge of anything they happen to find useful [3]. They will do worse things as compute becomes cheaper and cheaper.

If your argument is that there are lots of HTTP sites that are historically important and also that are unmaintained and that will never be upgraded, okay. That is a solvable technical problem [4].

If you want to know why you have to force people to do it, it is because security is a public health issue [5]. It is the same reason you have to force people to get vaccinations.

I don't work for Google (in fact I work for a direct competitor), and I disagree with a lot of the things that they do or want to do (unsurprisingly). But having more security on the web is not one of them. We live in a very different world than we did 25-plus years ago.

[1] https://www.eff.org/deeplinks/2014/11/verizon-x-uidh

[2] https://www.wired.com/story/the-dark-side-of-replay-sessions...

[3] https://theintercept.com/2014/12/13/belgacom-hack-gchq-insid... (search for MUTANT BROTH)

[4] https://archive.org/

[5] https://www.schneier.com/blog/archives/2014/03/security_as_a...

Longer answer: The codec needs to support it. Codecs actually allow prediction from multiple reference frames, and maintain a buffer of them (2 to 16, depending on the codec, profile, and level). An individual frame may refer to several (potentially all) of those. So re-scaling up to 16 frames for every frame you decode will get quite expensive, not to mention the generational losses of doing this repeatedly for every resolution change. In practice what happens is you scale individual blocks when they get referenced by the current frame. But that has to be integrated into the motion compensation routines of the codec.

Both VP9 and AV1 support this, for example.

Maybe you don't know how this works. Most (almost all) employees do not have access to these bugs, either. But community members can and do have access.

Early access to these reports can be worth literally millions of dollars in the wrong hands, and cause much more damage to our users. However, who gets access isn't decided by who gets a paycheck. It's decided by who is involved and participating and trustworthy. That can be literally anybody.

But a lot of people don't want to explain themselves or their reasoning, or get defensive when you imply that the time they just sunk into the approach they were taking was wasted.

It's helpful to remember that the people who have been working on a project for years might (but not always!) have a better perspective than someone who picked it up this week. If we're asking you "why", it's because we really are trying to help.

We're especially interested in figuring out how we can avoid leading other people down the path you went down (whether it's better documentation, or something else that would help). Because for every one who comes to us trying to do something insane, there's probably a hundred who are doing insane things and not telling us.

I have been paid by Mozilla to do this in some capacity for a decade. The budget for our entire team (which is the largest it has ever been), is less than the cost for just Mozilla to license H.264, by a non-trivial margin.

Here are some of the things that team has done:

- Made a Theora (VP3) encoder easily superior (in quality/bit) to what Youtube was shipping in Flash at the time (VP6), and (favorably) comparable with H.264 baseline.

- Developed and standardized the Opus audio codec.

- Provided infrastructure and maintainence for Xiph's older codecs (Vorbis, Speex, FLAC, etc.).

- Provided some minor assistance to VP8 and VP9 development.

- Made a from-scratch video codec (Daala) competitive with HEVC while avoiding the patents (i.e., with one hand tied behind our backs).

- Made significant contributions to a video codec superior to HEVC (AV1).

Now, maybe you want to call all of that almost nothing, but this code is in every Apple and Android handset in existence, and every current desktop browser, and used by some of the largest websites in the world (Youtube, Wikipedia).

The major concern with open source development is the free rider problem: why should Media Company X spend resources on an open source codec when Google will build one for them?

But the value current patent holders are attempting to extract from an individual licensee is larger than the cost for them to develop the technology from scratch by themselves. That value isn't created by the technology. It's created by having a common standard. And we don't need patents to incentivize that.

I think there are a few very specific skills you learn in programming contests that are useful in the real world:

1) Once you understand the problem to be solved, you can simply sit down and write the code to solve it. The ability to turn ideas into code in minutes instead of hours or days is invaluable. It lets you try lots of ideas, because the implementation step is easy. You can pick the ones that work and throw the rest away, and you don't mind throwing them away because they weren't a big investment. You don't realize how useful this is until you start meeting people who can't do it.

Our coach always told us that there is at least one easy problem, and someone's job the moment the contest starts is to identify it and bang it out. If we hadn't solved one problem in the first 20 minutes, we were already losing.

2) You learn to write code that is simple and correct the first time. Idioms that avoid special cases. Simple data structures ("No pointers!" was common advice, though of course reality was more subtle than that). Understanding when big-O complexity really matters, and when you can use a sub-optimal solution that's easier to code and reason about.

Sure, someone who is smart can write crazy complex code that only they can understand. But crazy complex code doesn't win contests. If you make a mistake you will burn all of your time trying to figure out what you did wrong, and the worse the code is, the worse of a hole you will dig yourself into. Write simple code that doesn't leave much opportunity for mistakes.

There's a scene in Jack Reacher where Tom Cruise's character says, "James Barr is a sniper. He's not the best. He's not the worst. But he trained non-stop for two years. What does training like that do? What does any training do? Skills become reflex, muscle memory, you do without thinking. It also makes people who aren't necessarily smart seem smart by beating some tactical awareness into them." That's what contest programming does.

3) You learn to identify your limits. There's usually (but not always) at least one problem you should just throw away as "too hard" for the time allotted. You won't solve it, so any time invested in it is a waste. In the real world, where you can't just decide not to do your job, that means you know the difference between when you can go fast and when you need to slow down and reflect. When you need to write a test to really know if the code you just wrote is correct. When it's better to step back and simplify the problem, rather than beat your head against it.

Yes, people like to focus on the "hard algorithms", but really this is not what makes good contest programmers. People aren't deriving Ford-Fulkerson on the fly during a contest. They memorize a set of canned algorithms and apply them when necessary. You learn to recognize and value simple, robust solutions to problems. You carry a toolbox of these wherever you go. This toolbox keeps growing long after you stop competing, and it contains a lot more than fancy algorithms.

Now, there is also plenty you don't learn doing contest programming that you still need to know in a real job. But these are the things I learned that have helped me.

I'm still waiting for the day I need to compute the coefficients of a rook polynomial, though.

Say, for example, you make a chip that does motion search acceleration and you want to sell it to people who do both AV1 and H.264 encoding. You'd be covered for any patents included under this license to the extent the chip was used for AV1 encoding, even though you didn't make a complete encoder. To the extent someone wanted to use it for H.264 encoding, your or they would still have to negotiate a separate license (just as you would have if AV1 didn't exist).

Source: I helped write this license.

We may return to Daala in the long term: it has competitive performance with HEVC on perceptual metrics despite a vastly simpler design than AV1 or even VP9, and despite being less mature than the classic block-based approaches and missing many tools that we simply didn't have a chance to implement (e.g., Daala has only basic MPEG2-style B-frames with no bi-prediction, as just one example).

Like the old adage says, if you have two baseball players who can run to first base in the same time, and one has perfect form while the other one looks lousy, which one do you pick? The guy with lousy form, because teach him the right form...

However, a lot of Daala's design is predicated on having a very constrained legal budget and not being able to rely on anyone else's patents. With the Alliance for Open Media, both of those constraints are relaxed. So even in the best case the result is likely to look pretty different from the way Daala looks today. Ultimately we're interested in making a codec people will actually use, and that means working with our partners.

However, as a result, the difference between an Opus decode and the original will only get you lossless reconstruction if you decode with the same build of Opus on the same machine. Also, since Opus uses IIR filters that ring to infinity, even on the same machine you only get bit-exact results if you decode each file from the beginning. It won't work if you seek.

Really, if you're concerned about the disk space required for separate FLAC and Opus encodes, delete the Opus version. FLAC decoding is extremely fast (5x faster than Wavpack), and Opus encoding is pretty efficient, too (on the same order as Wavpack decoding).

I tried to set up Let's Encrypt for this purpose for a personal project (to be given away as a gift), and concluded it was basically impossible as things are.

You don't want your users to have to figure out how to open their firewall enough for an http server to be publicly reachable just to use your device, especially when it has no other need for it. It would need to be reachable every 60-90 days to renew the certificates, which is frequently enough to mean "always".

The ACME protocol does have a DNS-based challenge mechanism, but it requires putting a token in a TXT record at an administrative sub-domain of your actual domain (e.g., _acme_challenge.example.com). As far as I can tell, none of the free DNS providers support or enable this (nor does certbot, without writing your own hooks). I don't want to eat a domain registration fee in perpetuity for a gift.

Sadly, there's no ACME challenge that can be satisfied solely by the actual thing you're trying to assert, which is that you control which IP address a given domain name points to.

Agreed, the discussion on these questions is the whole point, not whether you can come up with a "correct" solution (and I tell candidates this up front).

I generally draw a small example input with a cycle, and ask what their list-reversing solution will do with it, which I feel makes it much less of a trick question. "Can you work out what the code you just wrote will do with inputs that don't meet the assumptions you made?" seems like a fair thing to ask anyone who will be required to write code that handles untrusted data.

I've found that having common questions used across many interviews allows for more objective direct comparisons. I like this one in particular because even if they solve it quickly, you can move on to questions about cycles in the input.

What do you use now?