No, this only removes parsing CELT inside an ogg container (because CELT itself is going away), not support for ogg itself.
370 karma · joined January 6, 2013
Not just a war on Christmas, but an actual war too: this led to a whole bunch of Christmas riots throughout England, including Canterbury's famous "Plum pudding Riots", where rioters ended up sacking the mayor's house and taking over control of the city for weeks. The whole of Kent ended up revolting after the rioters' trial, essentially starting the Second English Civil War.
[1]: https://www.filfre.net/2026/03/the-mystery-of-rennes-le-chat...
As in, "how do I check if a string starts with a shebang" should result in some code being pasted in your editor, not in a new dependency. There is obviously a complexity threshold where the dependency becomes the better choice, but wherever it is it should be way higher than this.
It is however available in F-droid [1], and the newer versions don't need the secondary app and do everything internally.
The way a changeset goes from a developer's machine to the root is reasonably similar (it usually gets pulled through a number a intermediate trees, from a development tree to a sub-subsystem tree to a major subsystem tree to Linus's tree), riding the train from the bottom to the top, with an additional time constraint on it (the merge window being open).
The kernel also has a "next" tree that is a snapshot of what the kernel would look like with incoming changes merged right now, surfacing early the exact long-distance coordination issues described in the article. Plus, of course, everything is in the open, so maintainers of different subsystem can then coordinate directly on things that impact both sides, even if the required patches will if possible make their way up separately.
[0]: https://www.kernel.org/doc/html/latest/process/2.Process.htm...
Since mpv 0.34 it even looks for yt-dlp first, and fallback to youtube-dl otherwise. Before that you had to set an option, or just symlink youtube-dl to yt-dlp.
Well, there's Science Fantasy [1]: Jedi and the Force are very much Wizards and Magic.
I've heard it called Space Fantasy, too.
[1]: https://tvtropes.org/pmwiki/pmwiki.php/Main/ScienceFantasy
It allows different mounts to expose the same content with different ownership, and in general to map permissions IDs between mounts in any way we like.
systemd-homed wll use that to abstract over the uids and gids of portable home directories, for example.
It lists tabs by process, and includes the PID (on Linux; no idea about other platforms). You can also directly kill tabs and processes from there.
It's useful to quickly lookup the syntax for something you never use, for example. Or to browse and discover things you didn't know were even possible.
The Tim Traveller did a wonderful video on those a few months ago [2].
[1]: https://en.wikipedia.org/wiki/Toblerone_line
[2][video]: https://youtu.be/tPL9-L2gwzo
A "Kähler manifold" exists, as a name, because there is no way to fully describe what it is (and bring forward in the reader all the corresponding context) in two or three words. Using a long sentence (full of things that could themselves be artificial labels, recursively) instead would be a waste of everyone's time.
If one can use a short descriptive name for something, then it's not a name, it's just the thing, and everyone refer to it directly. And when you can't, or when you want to indicate its importance, or you want to neatly package all the relevant context about it, all the mathematical baggage that should come with it in something short, then the pretty obvious thing to do it to abstract it away and stick a label on top.
It doesn't really matter whether they use mathematicians, flower names or characters from The Lord of The Rings, as long as it's unique enough, in context, then it's fine. The names become part of the vocabulary of the field, just as much as supposed "descriptive" names. All those "descriptive" names have to be precisely defined too anyway, because they carry natural-language connotations, assumptions, and so on, that just don't apply.
The [edit: wikipedia] article mentions that he was "director of radio operations of the Psychological Warfare branch in the Office of War Information at Allied Force Headquarters": that's what became PWD/SHAEF [1] towards the end of the war and was merged after the war with the Strategic Services Unit and some other stuff to make the CIA.
[1]: https://en.wikipedia.org/wiki/Psychological_Warfare_Division
Good. User agents already contain too much.
That's actually the first time I've ever seen a browser actively removing stuff from the User Agent.
[1] https://shadycharacters.co.uk/2018/08/emoji-part-1-in-the-be...
AV1 support is available on all platforms behing the flag; this release just enables it by default on Windows [1].
Ah, that's what I was missing. Thank you, that makes sense.
So I guess my question is, why can't whatever it does to handle the ordering and merge the two be replicated in a small program that reads two names pipes and does the same but with extra colorizing?
For compatibility with DOS 1.x no less [0]! That's 37 years and counting of backward compatibility...
[0] https://blogs.msdn.microsoft.com/oldnewthing/20031022-00/?p=...
In languages where that difference matters, let's say Java/Scala [1], there are way too many possibilities:
- bug fix: forward and backward binary compatible; basically a drop-in replacement. Package managers are supposed to resolve conflicts between those automatically,
- new feature, but backward binary compatible; just some new code alongside the old. Package managers should also be able to resolve a conflict between dependencies that depend on different versions of those.
- bug fix: forward and backward source compatible; here we have a problem: we can guarantee developers that they won't have to edit a single line of code to migrate, but we can't allow (binary) package managers to do anything. They have to rebuild their library, which means bumping their own version number. And does that means that their new version becomes binary-incompatible with the previous one, or just their dependencies?... who knows? Maybe it depends on if the consumer of that library calls into the conflicting dependency directly or only uses it indirectly? Maybe not? Can we tell?
- new feature, backward source compatibility, but no binary compatibility; same as above: package managers cannot do anything, and conflicting transitive dependencies on the new and the old may or may not be solved by recompiling one's library. The only safe bet is to wait for the dependencies to upgrade.
- all bets are off (possibly split in minor and major): here at least we know there is nothing to be hoped. But in practice after upgrading to the new API, you are faced with the same questions concerning that thing's dependencies...
And if every dependency manager within the same packaging eco-system doesn't enforce a single global versioning scheme, how can they handle any dependency version conflict anyway? They could if packages could auto-describe their semantic versioning, so basically they can't, so they don't, and we're back to source dependencies, with recompile and bump in version number for every dependency change (ok, sometimes they do try and we get JAR hell...). And since a single versioning scheme isn't enforced, people use hundreds of different ones (or just none), and the maintainer of a library has to make all of those decisions, recursively (except that below 1 level of dependency, he/she might not be able to do anything as long as even a single dependency keeps an old conflicting dependency around, but they still have to check, in case they are lucky and can do something), taking into account the different versioning semantics of each dependency. That's madness.
So in the end, if we get a conflict between dependencies far down in the dependency tree, it becomes something pretty ugly:
- if guaranteed binary compatibility, everything is fine,
- otherwise:
0) look at that dependency's official versioning scheme, usually find nothing (except for big famous libraries)
1) pick the highest common-one, try to recompile your library
2) if it works, try the tests (your library's tests, not your dependencies' tests, mind you. Even though those should probably be run, considering they directly depend on it, and use (and hopefully test) more stuff from that library)
3a) it it works, ship it and pray.
3b) it will probably fail somewhere since the dependencies in between have not be recompiled; then you can only wait for them to upgrade.
I know in the end this doesn't work so bad (well, everything is relative...), but it still makes me sad that upgrading dependencies is still human-based trial and error.
Oh. I guess this is a rant.
[1] that's just what I am the most familiar with, but you could say the same with C packages in a distro's package repo, for example.
Increasing the limit would create too much bytecode, and in the current design, lifting the limit is just impossible (without runtime code generation or custom classloader, etc.).
This will break some tools, like Play's forms, that need you to pass to a couple of serialization/deserialization functions.
Shapeless will probably be fine, or at least, since it is macro based, it will be able to go around the missing unapply and extract the fields directly, like pattern matching does. (I don't know shapeless enough to go into more details)