People not spending money is bad... how? This doesn't slow the economy any,

The economic activity is the movement of money, broadly speaking. Without spending of money there cannot be economic activity, so not spending is literally slowing the economy.

Speaking of UKCA...

in my line if work is don't think I've had a single UK customer ask about it. CE is still valid here mostly and everyone still asks for CE marking. It's all B2B by the way.

But also since we can get away with just CE, why would we go for just the local one and have to recertify anyway for a bigger market.

companies started planning their exit strategies.

The strategy was so crystal clear, "brexit means brexit" after all, that companies had no idea even what to plan for. The bad ones buried their heads in the sand, the good ones wasted avst amounts of time and money having to cover all reasonable contingencies.

Naturally, in keeping with the entire theme, it wasn't just planning for exit, it was an utter shitshow of trying to plan.

There's a much easier way. Cut all fossil fuel subsidies, direct and indirect, to zero. End corporate welfare. Let people pay the actual, unsubsidized price, and you'll see things change pretty quickly.

you get a very disorienting "why won't it slow down" feeling, and it's easy to panic.

You don't always even panic. It's weird: if you do something in muscle memory enough, you don't consciously think about doing it. This is why driving etc is smooth because you aren't thinking about every action. When something breaks [see what i did there!] you at best get a creeping feeling of wrongness that takes a while to percolate up to your conscious brain.

I can relate a few anecdotes.

One typically dismounts a bike by first lifting your foot up off the pedal before putting your foot down. After an accident where I slipped off a pedal climbing a hill, I switched to toe clips, which require you to tilt your foot down then slide it up and out. Lifting doesn't work. First time I came to a stop, I toppled over into a puddle while hauling my foot upwards, but not even thinking about it. I wasn't panicking because I hadn't even noticed until I was at about 45 degees at which point I had a brief flash of "oh shi..." before landing in the puddle. But it's funny: lower level part of my brain wanted to lift my foot and just kept applying increasing force to match the requirement, but didn't inform me.

Next (harmless) was on moving to the US. I was driving along and then my partner asked me what was wrong, which confused me. She then asked why I was batting at the door. I had *NO* idea I was doing that. I'd only ever driven a manual on the other side of the road. Based presumably on engine noise etc, my hand was searching continuously for the nonexistent gear stick on the wrong side of the car. The weird thing was it was going all of its own accord. And because nothing had gone really wrong, nothing jogged my low level brain out of that loop, so it was happily searching forever, and my conscious mind was completely unaware.

Third was in winter, wearing heavy boots driving an unfamiliar rental canyonero, and clipped the gas with the side of my boot while braking. The car wasn't slowing properly, and the low level feedback control part of my brain just kept commanding more force, so I kept kitting both pedals ever harder. I got a creeping feeling of wrongness as the car wasn't stopping, but it's basically of the form "why is my limb not working properly".

I then rear ended someone, and I can't remember how I realised what the fuck I was doing. Anyway the guy was really nice.

Google, Microsoft, Apple, Facebook, Amazon, or another one of the big software development companies could easily fork ffmpeg itself, fix the open CVEs, provide their own (likely incompatible) features, and become the new standard - leaving the original developers out in the cold. Google did this with Blink (forked from WebKit, which itself was forked from KHTML). They took a fork of a KDE backed project, put it into what is now the #1 browser in the world, allowed Microsoft, Opera, and others to then use it in their own browsers — and now Google owns the entire narrative and development direction for the engine (in parallel to, and controlled to a lesser extent by Apple which maintains WebKit). The original KHTML developers really couldn’t keep up, and stopped maintaining KHTML back in 2016 (with full deprecation in 2023).

That is the risk for the original developers here. You’re right in that there isn’t really anything out there that can do what ffmpeg does — but if the developers don’t keep up on CVEs then organizations are going to look for new maintainers — and a year or two from now everyone will be using the Google/Microsoft/Apple/Facebook renamed version of ffmpeg instead.

That’s the shitty truth of how these things work. We’ve seen these same actors do it before.

Yaz

Look — I’m a developer. I get it. I’m personally all for having organizations do more to support the OSS they rely on. But the people in the C-suite are more worried about organizational reputation and losing money to lawsuits. If a piece of software they rely on has a known critical CVE that allows for remote code execution and someone breaks in and steals customer data — that software either needs to be fixed, or it needs to be scrapped. Those are the choices. Our customers in the EU are allowed to request SBOMs of everything we use and pass it through their own security validation software — and if they find sev critical CVEs in software we’re using there is going to be hell to pay. And the people in the C-suite can’t abide that level of risk.

Most software development companies (outside some of the biggest ones) don’t really have the kind of expertise in house to supply patches to something as complex as ffmpeg. But a company like Google has the staff with sufficient experience in this area that they could fork the project, fix the issues, and redistribute it as their own solution to the problem — and now Google is driving ffmpeg development. Organizations that need a security-guaranteed version will simply switch to Google’s version, which will likely slowly become incompatible with the original. They’ve done it before — Chrome was Google’s fork of WebKit, huge swaths of users flocked to Chrome, and now Google has over the years made enough changes that their patches often aren’t compatible with WebKit (and, of course, WebKit itself did similar when they forked KHTML).

Now forking like this is great for the community, but it can be tough on individual developers who see their work co-opted and then sidelined by massive corporations. And that’s really why the ffmpeg developers need to be very careful about ignoring CVEs like this. They do so at their own peril, as anyone can fork their code, fix the issues, and slowly make it incompatible with the original. And a big enough organization can ensure they’re fork becomes the new standard, leaving the original developers out in the cold.

Yaz

I love this idea! I've got friends and relatives of all ages who love board games, quizzes, murder mysteries and stuff like that. I can see these games, especially the Knives Out one, providing some really fun get-togethers.

Even if it is, and it certainly isn't, the growth is predicated on more electricity generation infrastructure being installed than the world can build right now. And that's all heavy industry, you can't spin up new capacity overnight. It's nonsensical.

What on earth are you talking about?

This dude always posts strange screeds in fixed width font with unusual punctuation. For you own sanity, I recommend not trying to understand him.

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.

Orgs basically have a choice:

1. Suck it up and deal with the whims of people you are not paying a penny to
2. Cough up some cash and contribute
3. Develop their own completely in house/pay for a 3rd party one

2 is almost always way cheaper than 3. Option 4 of "whine incessantly that people you aren't paying aren't working for you fast enough" really needs to stop. I suspect a lot of companies would rather do 3 than 2, because they are not rational.

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

How about a circle with underground rail acting as spokes on a wheel and also following the circle. Then the farthest point is the diameter of the circle. As you stated, a 170k perimeter translates to a 54km diameter. So worst case is you have to go a third of the distance and there can be more than one route. Its unrealistic that there won't be some sort of disaster over a long enough timeline. Fire/flood/tornado/terrorist attack/sandworms/etc will happen at some point. It seems like poor planning to not anticipate that and allow routes for emergency services to be blocked because there is only a single way back/forth.

You're talking 800 kph? The fastest operational train in the world is the Shanghai Maglev at 460 km/h in China.

How do you know if your card is considered a "reward" card before you swipe it? Can/will the new "reward" cards be cards that have rewards but don't get grouped as such?

Its not like cash is free to manage. Sure, credit card fees seem high, but its not cheap for a business to handle cash. There has to be lots of oversight, or that cash goes missing. That oversight is a lot of checks and balances and takes more labor and security efforts to manage. The benefit of credit cards is you can have a black box terminal your employees can use to verify payments but is nearly impossible for them to steal from, especially on a whim.

If they make credit cards start failing, more and more people will start paying with cash and both merchants and credit card vendors don't want that.