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

There is no reason why applications which choose to implement both types of interfaces can't do so. There's also no reason why users should be limited to one type of interface or the other. Both things coexist completely peacefully on Android. You can connect a mouse to your tablet (or even phone) and treat it like a desktop system with shitty storage (practically all phones, it takes a lot of power to have fast storage.)

The primary use case for tablet computers in olden times was data entry and acquisition, for example the military used their magnesium-case gridpads to do inventory.

The biggest problem with Apple for users probably isn't any of their anticompetitive shit, but rather their bifurcated OS. Software which could be sold on both platforms is commonly only on one or the other. Tablets have enough screen and enough power to do real PC jobs but are prohibited from doing them because Apple wants to sell you both an iPad and a Macintosh. Android-based tablets can run emulators to get around these problems, or run full apps which can run on ARM Linux in Termux or another solution. TBF Google seems to have Apple envy and is aiming to lock down their systems more and not less so maybe they will throw away this advantage.

OMG, I'm so stealing that ;)

Do they also provide build tools and allow customers to build and install their own images?

You have to have punishments to stop the people who are stopped by the threat of them. Those people do exist. We don't think about them much because the existing deterrents work just fine on them.

But you also shouldn't waste your time either believing that they will deter everyone, nor that stronger punishments will deter statistically more people. There are always those who think they won't get caught, and those who don't care.

Somehow authoritarians always forget the carrot. The stick isn't invalid, it just isn't a complete solution, and you shouldn't be rushing to apply it in all situations.

What's stopping you? There's definitely people doing this right now. Around a quarter of the continental US is BLM land. Last I looked pig tags were free.

"Woke" simply means "I'm conservative, and the thing I'm calling 'Woke' is something that I hate". It has no well-defined meaning beyond that. I've heard things as diverse as "the concept of the Metaverse" and "removing copyrighted content so you don't get sued" described as "woke".

No call by push value or P vs NP or complexity theory etc.

So a different set of things that are also useless to the vast majority of people?

Even when Chrome adds support, we'll have to wait ages before we can actually reliably use the format without having to implement fallback logic and fallback formats for legacy browsers.

AVIF is also painfully slow. And if I recall correctly, is outperformed by JPEG XL at moderate and low compression (but - again, if I recall correctly - AVIF wins at highly compressed images). Also, AVIF faces some patent threats. And misses a lot of JPEG XL's interesting features.

A practical issue with a circle is that it is not a circle until it is finished,

That's not the reason at all, AFAIK. The reasoning is, okay, we want people to be able to move from one place to some distance place in the city at the maximum comfortable speed, which is limited by G-forces. You have some guaranteed G-forces from first accelerating and then decelerating. But if it's linear, that's your only G forces. If it's curved, however, you also have radial G-forces.

The Line's train going from one end to the other (170km) nonstop is supposed to do it in 20 minutes, aka with a mean speed of ~510 kph. Let's say a peak of 800 kph. Now if we shape that 170km into a circle, that's 54km diameter, 27km radius. From the centripetal force formula a=v^2/r, that's 222,22...^2 / 27000 ~= 1,83 m/s^2, or a constant ~0,2g to the side. This is on top of the G-forces from your acceleration and deceleration. You can probably deal with ~0,2g in a train if everyone is seated without much discomfort, though it's double what's acceptable for standing passengers. But you can eliminate that if the city is linear (at the cost of increasing the mean distance that the average person has to travel to go from one arbitrary point in the city to another)

That's not to defend this concept. Because the city doesn't need to be 170km long; you can just made it more 2d and have the distances be vastly shorter (at the cost of just needing some extra lateral travel within the city). Honestly, if I were building a "designer" city from the ground up, I'd use a PRT (Personal Rapid Transit) system rather than trying to make it super-elongated.

What got me is that I don't see why this isn't readily resolved by active damping, the same systems that many tall towers now use to resist earthquakes or resonant wind forces. Big heavy weight at the top (or in this case the bottom) hooked up to actuators that make it move in an inverse direction to the sway.

Again, this is not to defend this colossal waste of money. I just don't see why there aren't ready solutions for this specific problem.

Agreed - but that said, there are space elevator alternatives, like the Lofstrom Loop / Launch Loop, which at least theoretically can be built with modern materials (and have far better properties anyway - not latitude-constrained, provides dV, vastly higher throughput, far more efficient, stores energy / can add cheap energy at off-peak times, etc). One could always "waste" money on them trying something new :)

You debunked your own comment, there's nothing for me to do here :)