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.
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.
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.
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:
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.
Than UNIX fork/exec model, or calling into Create Process all the time.
Windows has a more rich set of IPC stuff than POSIX, especially since it has a microkernel like design.
If you are going to say it is everything on the same memory space anyway, it isn't.
Optional on Windows 10, and enforced on Windows 11, Hyper-V is always running, and several components including kernel and driver modules are sandboxed into their little worlds.
Several additional sandboxing changes were announced at BUILD.
I would say that pipes and shared memory are the IPC mechanisms? Controlling the state of the exec'd process's file descriptors would counts as a way to set up interprocess communication, but once that's done, it's the pipe or SHM that does the actual communication.
The problem with POSIX IPC is that passing file descriptors between processes (other than parent passing to child via fork) is hard. Yes, SCM_RIGHTS can do it, but it is quite error prone and rarely done.
reply