TehPers

Rust currently isn’t as performant as optimized C code, and I highly doubt that even unsafe rust can beat hand optimized assembly — C can’t, anyways.

A bit tangential, but to answer this question, nothing beats the most optimized assembly code. At best, programming languages can only hope to match the most optimized assembly.

Rust does have macros for inlining assembly into your program, but it’s horribly unsafe and not super easy to work with.

Rewriting ffmpeg in Rust is not a solution here (like you’re saying).

The sheer scale of this across multiple sectors should put any fears that we’re not in a recession to rest.

Wow thanks. I feel so relieved now!

Seeing my own friends affected by both the layoffs and the shutdown (since their work is government funded), there’s no way the economy isn’t royally fucked.

Anyway, I’m no economist, so I won’t pretend like I can say what will happen, but it’s very clear something will happen, or we’re already in it (more likely).

Can’t wait to see what happens if/when AI’s hype dies too.

Also, when it comes to mounting radiators, all that matters at the end is where the air collects, and as long as a vertically mounted radiator has one end above the pump, then air will naturally collect there. Tube orientation matters, but not a whole lot. Tubes on the bottom usually means that air collects on the side of the radiator where it’s less likely to recirculate back into the pump, but mounting it the other way doesn’t usually cause issues because the air can still collect and what few bubbles make it to the pump aren’t significant enough to damage it.

TL;DR: the goal is to not run the pump dry, which should never happen as long as the pump isn’t at the top of your water loop (radiator below pump).

Eh the “radical left” is literally anyone opposed to fascism these days. “Left wing extremism” can’t be too far from that.

Wow genius response. Glad you actually addressed my comment.

ffmpeg devs can refuse the AI generated bugfixes for all we care.

This is a separate problem, but it’s still a problem. Many projects have seen a rise in slop PRs. curl is notorious for complaining about AI slop vulnerabilities and patch requests.

But I think we both agree that Google needs to be doing something more rather than putting the workload entirely on the ffmpeg devs.

Lemmy also benefits from not tracking total karma or whatever. Per-post or per-comment scores at most.

From my experience, Beehaw disabling downvotes furthers this even more. This means that people can either voice their disagreement, report the post/comment for violating the rules, or ignore it and move on. There’s no way to anonymously “punish” a post you disagree with (unless it violates the rules), and not as much incentive to stick to the echo chamber either.

Well if you categorize everything that isn’t alt-right as hard left, it’s pretty believable. I mean hell, have you seen Wikipedia? Clearly hard left.

I don’t understand how a bug is supposed to know whether it’s triggered inside or outside of a google service.

Who found the bug, and what triggered it? Does it affect all users, or does it only affect one specific service that uses it in one specific way due to a weird, obscure set of preconditions or extraordinarily uncommon environment configuration?

Most security vulnerabilities in projects this heavily used are hyper obscure.

If the bug is manifestly present in ffmpeg and it’s discovered at google, what are you saying is supposed to happen?

e) Report it with the usual 90 day disclosure rule, then fix the bug, or at least reduce the burden as much as possible on those who do need to fix it.

Google is the one with the vulnerable service. ffmpeg itself is a tool, but the vast majority of end users don’t use it directly, therefore the ffmpeg devs are not the ones directly (or possibly at all) affected by the bug.

There are a bunch of Rust zealots busily rewriting GNU Coreutils which in practice have been quite reliable and not that badly in need of rewriting. Maybe the zealots should turn their attention to ffmpeg (a bug minefield of long renown) instead.

This is weirdly offtopic, a gross misrepresentation of what they are doing, and horribly dismissive of the fact that every single person being discussed who is doing the real work is not being paid support fees by Google. Do not dictate what they should do with their time until you enter a contract with them. Until that point, what they do is none of your business.

Alternatively (or in addition), some effort should go into sandboxing ffmpeg so its bugs can be contained.

And who will do this effort?

If you’re seeing downvotes, it’s unlikely anyone on other instances can see them as well. Not sure how they federate, but Beehaw has them disabled, so they’re not on Beehaw.

Bug reports that apply only to Google’s services or which surface only because of them are bugs Google needs to fix. They can and do submit bug reports all they want. Nobody is obligated to fix them.

The other part of this is, of course, disclosure. Google’s disclosure of these bugs discredits ffmpeg developers and puts the blame on them if they fail to fix the vulnerabilities. They can acknowledge the project as being a volunteer, hobby project created by others if they want, and they can treat it like that. But if they’re doing that, they should not be putting responsibilities on them.

If Google wants to use ffmpeg, they can. But a bug in ffmpeg that affects Google’s services is a bug in Google’s service. It is not the responsibility of unpaid volunteers to maintain their services for them.

The issue is not whether security issues exist in ffmpeg. It’s clear that vulnerabilities need to be fixed.

The issue is with who actually fixes them. Your last sentence is the core of it. Google can submit as many bug reports as they want, but they better be willing to ensure the bugs get fixed too.

I think the last thing ffmpeg devs want is AI generated bugfixes to their assembly-heavy codebase. What they should do is dedicate time for experienced devs to fix the bugs instead.

You also won’t see too much critical of Google on their channel despite it being one of the biggest threats to privacy and safety, for obvious reasons. Can’t hurt the hand that feeds I guess.

Well this is a load of nonsense. You can see where they got funding for that investigation here. It was crowdfunded, after all.

As for the rest of your comment, “everyone knows something at a high level” is the dumbest reason not to do an investigative piece. It’s exactly that people only know it at a high level that investigating is important.

It would be way more interesting to know if now after china said no more nvidia if the flow of chips is ongoing, but they probably won’t ever cover that.

If you’re looking for another investigative piece as a follow-up to their previous one, then why don’t you email them directly? If you’re just complaining that there isn’t one, then can’t really help you there. The story of the GPU black market has already been told though, so the most they could probably really do is a hardware news segment if I had to guess.

GN’s last crowdfunded investigation into export-controlled GPU sales in China was a masterpiece of modern journalism. I have no doubt he wouldn’t fail to deliver here.

This sounds like an opportunity to follow 4chan (of all things) and politely tell them to fuck off.

If you believe they violated Beehaw’s rules, report them.

If you want to be in a space without moderation, then Beehaw isn’t for you. Moderation isn’t only spam filtering. If you believe that’s what moderation should be, that’s okay. But that isn’t what it is here or in almost any space.

Beehaw’s only rule is to bee nice. Surely anything that violates that rule isn’t worth any of our time to read.

Government-backed email would also help solve the “is this a bot” problem by limiting the number of email addresses that can be used, though naturally you’d also lose anonymity using that email.

There’s also the issue that if the emails are predictable, spam and phishing become much easier.

I’m mixed on this one. If we could choose the username and there’s no API for anything other than “is this a person” and your classic IMAP/SMTP stuff, then I’d be a lot more on board I think.

Is this your first time here?

Your account is brand new and you’ve already posted now three posts related to JPlus in this community in one day. Please tell me you’re joking with this one.

This post is a GitHub link to the project. Cool, I love seeing new projects, especially when the goal is to make it harder to write buggy code.

The other post is an article that immediately links to the GitHub. The GitHub contains a link at the top to, what I can tell, the same exact article. Both the article and the GitHub README explain what JPlus is and how to use it.

Why is this two posts when they contain the same information and link to each other directly at the top?