That, or your project gets sidelined. Which is where the danger lies.

I work for a big multinational software company that uses a lot of Open Source Software. We have a security office that audits all of our products several times a year. If any piece of our stack shows any open CVEs we have a fixed amount of time to fix the issue, with the amount of time varying from a few days (for CRITICAL severity issues) to roughly half a year for the lowest severity issues. A lack of a fix for a published CVE isn’t an excuse for not fixing the issue on our end — the software still has a security flaw in it, and the organization is so incredible security averse (thanks in part to having contacts in the defence industry) that they don’t want to risk expensive lawsuits and the loss of reputation if a vulnerability is exploited.

A lot of bigger organizations now work this way. We’ve all seen what has happened to organizations that have had significantly security breaches, and it’s not pretty. Our customers are big corporations and government entities — and if they even sniff a risk there are going to be problems. So if there is an unpatched exploit, we’re expected to either switch to something comparable, or DIY a solution (either replacing the library in question, or potentially patching it ourselves).

If ffmpeg allows known and published vulnerabilities to languish, the risk here is that organizations that use their code will simply stop using it and will look for other solutions. That’s a tough pill for an Open Source Software developer to swallow, especially when they make it as big and important as ffmpeg. You might wind up in a situation where an entity like Google forks your code and takes ownership, and eventually gets everyone to migrate to using their version instead (like what they did with WebKit to Chrome), leaving you sidelines. Or maybe someone else jumps in with a compatible solution that works well enough for enough users that they switch to that instead.

Now in an ideal world, the Google’s of this world would not only submit a CVE but would also submit a patch. Having been an OSS developer myself I’ve always encouraged my staff if they find a bug in a piece of software we use to file a bug report and ideally a patch if they know how to patch the issue correctly — but I know that is hardly universal within our organization, and probably even less so elsewhere.

TL;DR: a lot of OSS success relies on having lots of users, or at least some big and important users. But you risk losing those if you leave CVE’s open for too long, as company policies may require scrapping software with unfixed CVEs. That loss of users and reputation is dangerous for an OSS project — it’s how projects get supplanted, either by a fork or by a new (and similar) project.

Yaz

What if you broadcast a concert, unencrypted, over the airwaves and then insert a message every so often, "you may not listen to this program"? That designates your intent that no one listen, but it is not an effective technical protection measure because you are broadcasting to everyone in the vicinity, in the clear, in a format they understand. It is like putting up a billboard on the side of a highway and expecting no one to look at it. Not effective at all.

I asked chatgpt how long it has been part of culture, and it confidently said it's been 26 wonderful years.

A bit of kindness would not go to waste.

For example, try understanding why the summary mentions "It requires non-algorithmic understanding" a full three times. It's like asking the square root of a million... no one will ever know.

And the price! They must think we're flush with cash.

MTBF is useful information, but I think it would be more useful in conjunction with factors like active spinning time, total spin up/down counts, cumulative head seek time, total IO, etc. Presumably time-in-service affects the MTBF more than the age of the drive, but to what extent? Is a NIB drive that's two years old going to be as reliable as one that's only a month or two old? So many variables....

The headline is not even half true. The Pentagon is asking reporters not to solicit the commission of a crime. If someone gives them unauthorized information they can report it all they want. That issue was settled in the Pentagon Papers case more than fifty years ago. The previous article and the linked articles have this right.

The internet is really the best medium for sarcasm.

Pretty sure this opens him up to a legal malpractice suit. Probably more lucrative than whatever the debt was.

I keep telling people this, and they keep saying I'm wrong, something about it not being an actual accepted or useful definition of insanity, just a meme that caught on at some point. Their refusal to see the truth is driving me f'ing crazy!

lasting ecological shifts will hinge on design and long-term care.

We don't really know that for sure. It may improve the odds, but neither desertification nor greening require human intervention, nor is human intervention necessarily going to achieve the desired outcome. Life, uh... finds a way. (Except when it doesn't.) But for all we know (and what seems most likely absent evidence to the contrary), this is just a temporary oasis of sorts that will last only as long as the structures on the site.

The article is sparse on details. I don't necessarily think driverless cars should be given a free pass -- in fact, we should probably have higher fines for the manufacturers -- but 9 times out of 10 when a road is blocked, it's because of construction or an accident, not a checkpoint. I suspect it was reacting to the obstruction, because when a road is obstructed, the "no U-Turn" rule generally doesn't apply (or isn't enforced anyway). In fact, if it hadn't been a checkpoint, I doubt they would have even been looking for illegal U-Turns, which are indicative of people trying to avoid the checkpoint, presumably.

As for fines, I do think they should be higher for self-driving cars, because $300 isn't even a slap on the wrist for Google. On the other hand, that could create a perverse incentive where officers are ignoring flagrant violations by human drivers in favor of issuing a $100k ticket to a Waymo that veered out of its lane to avoid a hazard. It could also create a situation where self-driving cars are so cautious that traffic is snarled by puritanical robot cars that won't even approach the speed limit because it's not worth the risk.

If you train a system with protected content in a way that makes it possible to produce a duplicate of that content or an identifiable, non-trivial portion of that content under any conditions, your system is a derived work of the input, and you cannot use it to create additional derived works of the input without permission of the copyright holder unless whatever it is you are doing qualifies as fair use, which seems relatively unlikely if your system can replicate its inputs wholesale and those inputs have commercial value as such.

Systems like that that process images, audio, or video in particular tend to look like a walking talking copyright violation of the first order and unless you basically want Congress or whoever to eliminate copyright protection as we know it someone had better figure out a way for such systems to identify what is uniquely protectable about everything they scan (brute facts probably not for example) and either not to scan it or to quit parrotting anything that is. The same rules that any human author, creator, or publisher is required to abide by in other words. Just because you consume enough electricity to boil the oceans does not give you an exemption from federal law.

The questionable nature of all this aside, this does not appear to be a government seizure of the funds in all the remaining accounts. Those funds simply remain inaccessible until the account owner goes down in person.

According to the Comsure Group: Funds Status: Contrary to some viral claims of "seizure," official SBV statements describe this as a cleanup, not forfeiture. Funds remain in the accounts but are inaccessible until verification. Recovery is possible by visiting a bank in person for biometric scanning—challenging for expats or those abroad. Crypto advocates and some media outlets highlight the risks of prolonged inactivity, which can lead to potential escheatment (funds reverting to the state), but no widespread seizures have been confirmed.

For a variety of reasons I think the desire for a "cashless" society is just short of insane, but it would be interesting to find out why the people in charge in Vietnam felt that this was such a great idea. To me it sounds like a good way to cause a minor dent in your GDP, waste a lot of people's time, and make life *really* inconvenient in any area where there is some kind of natural disaster, long term power outage, or other technical failure.