Sometimes I wonder if Vanguard is actually a government pet project for practice blocking and executing malicious pci devices.
You take one of those pci dma cheat cards, put a modem in them, and you've broken secure boot. And nation states have done such a thing to compromise laptops or other devices after getting physical access to them for a bit.
It might be appropriate for ffmpeg to get rid of such obscure codecs
This is why compilation flags exist. You can compile software to not include features, and the code is removed, decreasing the attack surface. But it's not really ffmpegs job to tell you which compilation flags you should pick, that is the responsibility of the people integrating and deploying it into the systems (Google).
Sandbox them somehow so RCE’s can’t escape from them, even at an efficiency cost
This is similar to the above. It's not really ffmpeg's job to pick a sandboxing software (docker, seccomp, selinux, k8s, borg, gvisor, kata), but instead the responsibility of the people integrating and deploying the software.
That's why it's irritating when these companies whine about stuff that should be handled by the above two practices, asking for immediate fixes via their security programs. Half of our frustration is them asking for volunteers to fix CVE's with a score less than a 6 promptly (but while simultaneously being willing to contribute fixes or pay for CVE's with greater scores under their bug bounty programs). This is a very important thing to note. In further comments, you seem to be misunderstanding the relationship Google and ffmpeg have here: Google's (and other companies') security program is apply pressure to fix the vulnerabilities promptly. This is not the same thing as "Here's a bug, fix it at your leisure". Dealing with this this pressure is tiring and burns maintainers out.
The other half is when they reveal that their security practices aren't up to par when they whine about stuff like this and demand immediate fixes. I mean, it says it in the article:
Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and listen to me … ”
Anyway, the CVE being mentioned has been fixed, if you dig into it: https://xcancel.com/FFmpeg/status/1984178359354483058#m
But it really should have been fixed by Google, since they brought it up. Because there is no real guarantee that volunteers will fix it again in the future, and burnt out volunteers will just quit instead. Libxml decided to just straight up stop doing responsible disclosure because they got tired of people asking for them to fix vulnerabilities with free labor, and put all security issues as bug reports that get fixed when maintainers have the time instead.
The other problem is that the report was AI generated, and part of the issue here is that ffmpeg (and curl, and a few other projects), have been swamped with false positives. These AI, generate a security report that looks plausible, maybe even have a non working POC. This wastes a ton of volunteer time, because they have to spend a lot of time filtering through these bug reports and figuring out what's real and what is not.
So of course, ffmpeg is not really going to prioritize the 6.0 CVE when they are swamped with all of these potentially real "9.0 UlTrA BaD CrItIcAl cVe" and have to figure out if any of them are real first before even doing work on them.
The respawns take forever
They take much less time now, but back when respawns took 10 minutes instead of 3, I used to do homework/work between rounds.
I got a TON of work done that way.
I honestly don't know how this could turn out.
It could be an amazing change that results in much more progress for hardware acceleration on guests of various types (since that is what vmware is good at) in kvm...
Or it could mean that they are dropping that feature from vmware altogether.
Regardless, I like this change because it means I would be able to run vmware machines and libvirt kvm machines at the same time, at least when I am forced to use vmware workstation.
I also dislike proprietary software in general, so I think less proprietary software and more FOSS is a good thing.
I use cromite, and it's good, but the adblocker is unable to handle the more aggressive popups and ads, whereas firefox + uBO does fine.
Thus, cromite is my main browser and I use firefox for... other stuff. This setup is mainly because I'm too lazy to install Mull or another firefox based browser to be my main option.
Also Black here!
(My keyboard doesn't have emotes, but pretend this is the black hand waving hi)
Edit: 👋🏾
Well damn, I guess fraud must be a lot more widespread than I thought. Because no one seems to get punished for this behavior. Just recently, Lockpick, a tool for getting Nintendo Switch roms off a physical device, was dmca'd, and the person who filed the complaint admitted to doing so on twitter. They received no punishment.
I think it's likely that this is a similar case.
If you're not on archlinux, you should probably switch. It has the latest packages of everything, and the Arch User Repos are essentially compiling whatever xyz program you want from source, in one command.
You should also be careful with doing stuff like installing deb/rpm's directly from sites, because that's how you can break your system. Also, I suspect you installed pip packages to the system itself, which can also can break your system.
Anyway, mesa, a "system" package is definitely more challenging as well, since it needs to be deeply integrated into the system. If you actually need a newer version of it, then the easiest is to just switch to a distro that has a newer version, or if you only need the userspace version, you can use it within a docker container like the one's offered by distrobox or junest.
If you were wanting a newer version of an "application", flatpak would probably be good enough to get it onto your system. "Applications" don't need to be as integrated with the rest of your system.
As a rebuttal to your post though, there is a very good reason why Linux does packaging the way it does. Installing a program on Windows is nowhere as simple as it may seem to you.
You probably have an adblocker, and use a non google search engine, and know your way around sites. But consider the average users actual process of installing a program on Windows. It looks something more like:
Of course, to you the process probably takes 15 seconds. But to a real average, non advanced user, this experience is fraught with risks. If they select wrongly, then they get malware on their computer. Compare this to installing software on Linux from a distro's repos:
No risk. No pain. Simple.
There is a very good reason for older packages in distro repos as well. There are two main reasons:
The first is stability. Stability vs unstability doesn't mean anything about system reliability, but is instead about lack of change. I like to say that a stable release distros doesn't just mean you older packages, it means you get the same system behavior over a period of time. Instead of a constantly changing set of bugs, you deal with the same set.
I like Arch. I like new packages. I can find workarounds for the current annoying bug this update cycle. But the average user probably doesn't want to have to deal with that. They probably don't want to have to deal with the bug of the week, and they would rather just have some predictable bug that stays there for a few years that they already know their way around.
I remember watching a twitch streamer hit this, actually. They were complaining about new packages, and I pointed out that the reason why older packages are there is to have the same predictable set of bugs, instead of a changing set. They dismissed me, claiming they needed new packages, which is understandable. But then they (an ArchLinux user) immediately encountered an issue with Dolphin (Linux file browser) where the top bar / UI wouldn't load at all and got really frustrated. I didn't say anything, but I did laugh to myself and feel vindicated when it happened. Of course, eventually that bug will be fixed. But new ones will come along.
The second reason, is supply chain security. Debian, and Red Hat Enterprise Linux, where not affected by the XZ utils backdoor, due to having a policy of only doing carefully cherry picked security updates. I won't go into detail here, but I have another comment about it.