Yeah I normally use Nushell as well. It was the one cross-platform shell I really liked.
I’ll still use it. I just need to find something a bit closer to bash for when I need to use bash commands to do something, or where working in an environment where others use bash. Nushell has some pretty major syntax differences like && not being used to “chain” commands.
Eh the “radical left” is literally anyone opposed to fascism these days. “Left wing extremism” can’t be too far from that.
From what I’ve seen, the hard drive at least looks replaceable, so it should be possible to upgrade it I believe.
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.
About time. The penny isn’t worth the metal it’s minted on anyway.
Unrelated, but the archive link isn’t loading for me strangely. I’ll keep trying throughout the day and see if it loads.
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.
So you’re saying that people driving from Dallas to San Antonio isn’t a good long term solution as the state population grows? Unbelievable.
I really don’t get what the obsession with driving is. I hate driving though, so I’m obviously biased. But by pretty much every metric, alternative methods of transportation can be way better than driving, especially at scale.
Not going to lie, at first I forgot that Fish was ported to Rust and was confused why this was posted here.
I need to give Fish another try now that I’m on Linux. It’s a great shell, but I couldn’t really use it on Windows.
As a format, I agree. Standard’s power balance got obliterated after Bloomburrow and Duskmourn. Still, I held hope they’d eventually get it back under control, but it’s only gotten worse since then it seems.
Standard stopped being playable or interesting to me since after EoE. The UB sets killed my interest entirely.
I already do #1, and I push for #3 (specifically Python or TS) where I can at work, but there’s this weird obsession with bash that people have at work despite all these scripts not running on Windows natively (outside WSL). Currently I do #2, but I often end up just stuck in bash the whole time because it’s needed for things as simple as building our code. I want to try out Fish as an alternative for those situations.