Also, good for Homie the Clown from Living Color TV show.

Not sure because these chips cost so much to operate in energy costs. If enough efficiency gains are made it would be cheaper to buy and run new ones than to run old ones to do the same tasks. When data center companies start building their own nuclear power plants you know there is a LOT of money to be saved by increasing efficiency.

... Larry Ellison!

For an additional fee.

THAT, I believe, is the main part of this change. Ryan Air already doesn't even break even on the pure ticket cost. It's the horrendous extra fees that make it profitable.

Which cost, exactly?

We are speaking about paper boarding passes the customers themselves print. The gates read the barcode and don't care if it's on paper or a phone screen.

So which cost, exactly?

That's putting it mildly.

Smartphones can crash, run out of battery or any number of problems. On important trips I usually have a paper boarding pass with me as a backup. Only needed it once, but I'm just one person with fairly normal travel amounts. Multiplied over the number of people flying Ryan Air, statistically speaking this happens constantly.

Frankly speaking, I think it's a gimmick to milk the customers for more money. Someone at Ryan Air has certainly done the calculation, estimated how many people can't access their boarding pass at the gate for whatever reason, and how much additional money they can make by forcing all these people to pay the additional fee for having it printed.

By the same token, I was reading for years how China's construction market was the biggest bubble in history and was going to pop so hard the nation would be an economic black hole. Is that still going to happen or what?

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

Look what he responded to.

People toss out a throwaway allegation and then expect you write a dissertation to rebut it.

Mostly true but not entirely. For the moment at least there are still applications such as airplanes where fossil fuels have no reasonable alternative. But yes, a large number of things that we currently power by burning long-dead dinosaurs could just as well work with other sources of energy.

And yeah, I think the whole world looks at the Middle East and is thinking: If you all so much want to kill each other, why don't we just step back and let you?

Some born with golden spoon in mouth boy is learning the expensive way that no, money can NOT buy everything. The laws of physics don't care how rich you are or how much money you throw at them. :-)

... please bring it back! I don't like huge and heavy iPhones!

Another way to go would be to keep burning jet fuel but purchase bricks of carbon from a sequestration company that captures it from the air.

I know there are more efficient types of carbon credits, like investing in cleaner energy in the first place, or increased efficient at the point of usage such as insulation, or preserving rainforest that would otherwise be developed.

The problem is all that gets complicated and thus subjective. Maybe carbon credits could work if it is based on a new type of 'coin' that is 1 kg of pure carbon that is chucked into an old mine.

That truly is the question for Apple. I don't know how they've held off smartphone commoditization as long as they have.

Obviously, sooner or later we will want to do things that require our physical presence. And be it because the ping time to Mars really, really sucks.

Robots are way easier to engineer for space than humans, even though space is so unforgiving that that's not trivial, either. The same is true for other planets. Building a robot that works well in 0.2g or 5g is an engineering challenge but doable even with today's tech. Humans... not so much.

But let's be honest here: We want to go out there. The same way humans have found their way to the most remote places and most isolated islands on planet Earth, expansion is deeply within our nature.

So, robots for exploration to prepare for more detailed human exploration to prepare for human expansion.

And maybe, along the way we can solve the problem that any spaceship fast and big enough to achieve acceptable interplanetary travel times (let's not even talk about interstellar) with useful payloads is also a weapon of mass destruction on a scale that makes nukes seem like firecrackers.

Has What If? already done a segment on "what happens is SpaceX's Starship slams into Earth at 0.1c" ?