I mean the collapse of the AMOC has been a hypothesized consequence of climate change for at least many decades. I was taught about it as something scientists think could happen in primary school; it's not new (tho it was framed in terms of the gulf stream, since that's the part of it which would affect Europe). Those fears were also founded on data-based climate prediction models.

It's also a command line tool, where you can design (limited) media graphs: sources, sinks, filters, encoders, decoders, muxers, demuxers. You don't express it as directly as gst-launch's pipeline syntax, but it's very much a pipeline.

Or .. their operating system and kernels

GStreamer is not "just a different front end to ffmpeg". GStreamer is a pluggable media graph system.

"GStreamer" doesn't link against libav. The GStreamer plugin "gst-libav" links against libav. If you're not using the gst-libav, you're not using ffmpeg. I'd bet a relatively small amount of GStreamer use cases use gst-libav; I typically see people use e.g x264dec and x264enc (from the x264 plugin) to decode and encode media, or, for hardware encoding/decoding, the v4l2enc and v4l2dec elements (or elements from a SoC vendor's plug-in such as gst-rockchip). It also has its own non-libav elements to handle container formats, pixel format conversion, scaling, etc, which are more natural to use since they're part of the core gstreamer plug-in packages rather than gst-libav.

100%, VAT is a regressive tax. Poor people use a large portion of their wealth on products and services. Rich people use a much, much smaller portion of their wealth on those things.

Plus rich people all have companies pay for a lot of their stuff. Need a new laptop? Buy it through your company. Internet and cellular plan? Company. New cell phone? Company. Many even have their cars paid by an compaby. All those purchases through your company are VAT exempt. Poor people buy their own laptops and their own cell phones and have their own Internet subscription and cell plan and car. They pay the VAT.

I'm in Norway, where the standard VAT rate is at 25%. I don't understand how such a vast regressive tax is so uncontroversial here. Get rid of it and replace it with a larger wealth and capital gains tax.

And the fact that Mozilla used licenses for FirefoxOS which allowed a closed-source fork to come in and take the market is a huge loss.

To some degree, yeah they did, by leaving space for a lean and mean competitor like Google Chrome to come around and eat their lunch. And when it was introduced, Google Chrome truly was the lean and mean browser, less bloated than both Firefox and IE.

But I'm not sure how much they could've done. Maybe they could've invested a ton of engineering resources into a project similar to Firefox Quantum earlier, so that Firefox didn't leave as much room for a leaner browser? But half the reason people complain about Firefox today is that they broke XUL extensions, which was an absolutely necessary step in making Firefox a competitive, fast browser. I can only imagine the backlash they would've seen if they did that before Chrome ate their lunch.

And I'm not sure how much it would've really helped, since 1) Chrome would've still been a less bloated browser simply through having been around for a shorter time and having fewer features, and 2) Google would've still had immense marketing opportunities by plastering Chrome ads all over Google Search etc.

Hahaha that's amazing, just a big red "RETIRED" badge above their blog post? What the hell

Breaking changes have had that tag for ages

Really? Retired? What does that even mean in this context, why not "breaking" or something else that suggests breaking change?

> Retired? What does that even mean in this context

"retired" is probably a followup to functionality that was "deprecated".

I agree "breaking" would be clearer

What exactly is it that's now retired that used to be deprecated? Isn't this just a collection of breaking changes to defaults?

if you go to the full changelog on the blog and click on the "retired" button, the url will have type=deprecations as the parameter.

It's a holdover from previous posts where there were more clearly defined deprecations.

but yes, in this case it's more of a behavioural change of defaults, so they just picked the closest vaguely mapped retired/deprecations tag.

1: https://github.blog/changelog/?type=deprecations

The interpreter knows types at runtime, not at parse/compile time. The interpreter already does a lot of dynamic type checking. It has a much stricter type system than e.g JavaScript; JavaScript will pretty much always convert operands to produce some result (even if it's just NaN or the string "object Object"), while Python will often just give you a type error.

The interpreter doesn't know about static types.

I agree that they should've made typing more a proper part of the language and not left it in this weird half-defined state of "standard syntax and some standard typing imports but undefined semantics". But it's not just a matter of enforcing existing types.

I do think it is somewhat of an all or nothing thing. I can write dynamic languages, sure; I prefer having static types, but I have written a lot of dynamically typed code. However if I'm working in an editor with LSP integration, the experience is much worse when some things are missing types.

As an example, I may have a variable with types:

    const something = somelibrary.getSomething();

and I can type `something.` and see methods and properties. However, if my own code doesn't use types consistently, it's so easy to lose type info. For example:

    const something = someWrapper(someLibrary.getSomething())

or:

    function doSomethingWith(something) {
        ...
    }
    doSomethingWith(someLibrary.getSomething()

or any number of other patterns which accidentally strips type info from the variable if you don't use types everywhere.

I would much rather have a language where the compiler complains if some variable doesn't have a static type, than a language where I can accidentally leave something untyped. I don't understand which case I would want a variable or function to not have associated static type information.