As in another comment, adding code/fixes only adds more work to the existing ffmpeg team as they need to review and maintain it forever. It's not good enough. Even security fixes in the style of "drive-by patching" are derided in security-oriented open source projects.
Adding code/fixes is a tiny fraction of work compared to reviewing and maintaining.
The only reasonable way is for Google and other big corps to either sponsor members of the existing team or donate money to the project. And making it long term not one-shotting for publicity.
It's frustrating to me how many people are siding with FFmpeg here considering how unprofessional and generally asshole-ish they are being.
I feel that this is mostly a kneejerk reaction to AI and Google in general, with people coming up with arguments to support their reaction after already forming an opinion.
It's a volunteer project, they have no requirement to be 'professional'. That's basically the root of the whole issue. A hobby project is not a product, and its developers are not vendors. Free software is not a supply chain.
(that said autovectorization should work, and fixed-width SIMD should map to RVV as best as possible, though of course missing out on perf if ran on wider-than-minimum hardware not on a native build)
They wanted to demonstrate why their move away from Apple CarPlay and Android Auto is a bad idea and why people shouldn't buy their cars (if they care about them still functioning after 4-6 years).
> why people shouldn't buy their cars (if they care about them still functioning after 4-6 years).
People have had 45 years to get the message. My Michigan parents' lives changed[0] when they got their first Toyota after a lifetime of Big 3 vehicles. Too bad it took so long to get out from under the indoctrination.
[0] Okay I exaggerate but really nice having a vehicle without something constantly broken and/or leaking
Maybe - likely we’ll trade-off the added build/test/storage cost of maintaining each variant - so you might not see amd64v4, but possibly amd64v5 depending on how impactful they turn out to be.
The same will apply to different arm64 or riscv64 variants.
People keep saying that, but haven't we learned already that eventually Tailscale gets bought, then priorities change, then they make incompatible changes because they're need to grow, and headscale either can't keep up, or gets pushed away by Tailscale themselves, and we're back to using $TailscaleCompetitor who promises to not do the same thing.
Just don't rely on centralized for-profit entities, rely on stuff produced by non-profits and foundations, that you know isn't gonna screw you over as soon as they need money.
> Just don't rely on centralized for-profit entities, rely on stuff produced by non-profits and foundations, that you know isn't gonna screw you over as soon as they need money
What do you use that fits that philosophy and offers the basic functionality (NAT traversal, Magic DNS, failover relaying) TS provides?
While I agree in spirit, I find this logic around for profit FOSS projects a little backwards sometimes, because it implies forking Tailscale wouldn't save much time.
What makes you think we'd be better off building a competitor to something open source if it has all the features we want now? The reason we don't see open source competitors to big products is not because people are too dumb to try it. It's because it's way, way harder. It makes way more sense to Fork and work from there while we're still getting this momentum from Tailscale.
If you think Headscale is going to have problems keeping up with a private Tailscale, good luck rebuilding Tailscale.
SDN is great if you're trying to build something like a multi-tenant cloud on top of another network of machines. Your DPUs can handle all the overlay logic as if there was a top of rack switch in each chassis
