I wish everyone knew the difference between patents and copyright.
You can download an open source HEVC codec, and use it for all they care according to their copyright. But! You also owe MPEG-LA 0.2 USD if you want to use it, not to mention an undisclosed sum to actors like HEVC Advance and all the other patent owners I don't remember, because they have their own terms, and it's not their problem that you compiled an open source implementation.
Ah, much better source: iOS is the answer to where the vulnerability was – right in the headline. I could not find that by searching for the usual keywords in the original post.
I see this as an attempt at a lesser evil, and I would support that (see my EME DRM comment), but I have one concern:
Does this new "privacy preserving attribution" feature respect multi-account containers? Or is it somehow not considered necessary, because it's meant to be less invasive than the tracking cookies it's supposed to replace? Call me skeptical for now.
I'm a happy user of multi-account containers, which lets me separate my cookie identities in Firefox. Before, I had to use different browsers for work and private, and yes, it solves this problem, but the best part is that I don't have to worry about tracking cookies, because they aren't tied to my personal accounts: In my experience, I can to a great extent escape the echo chamber I'm in, and the ads I see in it, by just deleting the cookies of my sacrificial default container.
Other than that, considering the status quo – that the web is already an unfriendly GDPR nightmare, I'm positive to the initiative. And because of the power of the default, I can understand that the feature wouldn't likely take off if it was opt-in, so I won't criticize Mozilla for that move either.
This has happened before. Remember the critique against Encrypted Media Extensions (https://en.wikipedia.org/wiki/Encrypted_Media_Extensions): Oh no, DRM in the browser! But remember that web video used to require Adobe Flash for the longest time, and even after a decade of HTML5 video, sites were still clinging onto Adobe Flash (and later also Microsoft Silverlight) for what turned out to be DRM purposes. At the time, these plagued proprietary blobs were not going anywhere. Except, after EME had widely supplanted this last holdout usecase, they were quietly allowed to die. The result is that we have much smaller-scoped proprietary blobs in the form of content delivery modules with a lot fewer bugs and portability issues.
Why haven't more people heard of git revise?
Unless you actually want to transplant your changes onto a new base, honestly, do yourself a favor and use this instead:
Its inability to change your worktree (operates in memory instead) is a big speed and safety feature: It won't invalidate your build, and you can't screw up the end state.
It also has features that regular rebase lacks, like splitting a commit and editing all commits at once.
I'm more than a big fan of it.
The following heuristic has become increasingly true over the last couple of decades: If you have some kind of "charset" configuration anywhere, and it's not UTF-8, it's wrong.
Python 2 was charset agnostic, so it always worked, but the improvement with Python 3 was not only an improvement – how to tell a Python 3 script from a Python 2 script?
* If it contains the string "utf-8", it's Python3.
* If it only works if your locale is C.UTF-8, it's Python3.
Needless to say, I welcome this change. The way I understand it, it would "repair" Python 3.
I'm skeptical because C++ is a slippery slope. Glad to see they are going for templates and concepts, and not constructors and destructors.
Yes, what C++ is supposedly good for – RAII, it actually got a little wrong:
1. Default construction / value initialization: Causes lots of initialization before assignment that is obviously unnecessary. Try allocating a buffer: `std::make_unique<char[]>` surprisingly memsets the buffer.
2. Constructors: No way to fail without exceptions. That buffer example again: Without exceptions, `std::make_unique<char[]>` will actually attempt to memset a nullptr on allocation failure … before your nullptr check (which btw makes the compiler entitled to delete your nullptr check as well).
3. Move is a (burdensome) runtime state that mandates nullability.
4. Destructors: Can't take arguments, forcing objects to contain implicit references to each other.