Primarily because Resolve is meant as a tool for professionals - and as a result it can’t get away with using things like Ffmpeg under the hood.

Ffmpeg (for example) doesn’t use officially licensed codec SDK’s to handle certain codecs - it uses reverse engineered tooling.

If you’re working on a personal project or something that is just getting pushed to YouTube that won’t matter 99% of the time.

However if you are working on a professional color grading pipeline for a project that might go to broadcast or into theaters, there are very specific QA tests that the final rendered product must pass - and these unofficial reverse engineered rendering tools often result in rendering errors that can fail these QA tests (and in a way that is basically impossible to troubleshoot).

It’s already enough of a challenge to manage a color pipeline using the officially licensed tools - they can’t really risk that kind of issue with their pro and semi-pro customers.

That said, it’s important to note that MP4 is a just a container/wrapper, not a codec.

So an mp4 file might contain video (or just audio) that is rendered using one of many possible codecs depending on what was chosen by the person doing the render. That will determine whether Resolve whether the free edition of Resolve will support it or not.

If you prefer driving towards Linux all that is necessary is to migrate your TrueNAS CORE instance to TrueNAS Scale which is Debian based. (It is reportedly fairly painless).

This specific project is for people that didn’t like being pushed towards Debian and wanted to stick to BSD.

I’ll also include entries in the .github dir in project repos doing same thing in case anyone working on it happens to use GitHub copilot via vscode will also pick up on the AGENTS.md as well as any skills I might have cooked up for the repo.

(Though it’s mostly because I don’t trust team members to read the docs and the skills I made are meant to guide following standards for the project - and this approach almost incepts the standards for anyone not paying attention)

At best adoption is delayed a while until the marketing department figures out a strategy that is more palatable.

The question was why Podman doesn’t have the adoption levels that Docker does, and my supposition was that (for those that don’t have much Linux administration experience) added steps like systems configs, or quadlets etc are just another barrier to entry that you don’t have with Docker.

I’m not arguing that Docker is better (I think Podman wins in a lot of ways actually) just that Podman requires a bit of extra work to implement well and that is just enough of an annoyance to tip the scales towards Docker.

It definitely can solve some of those problems, and that’s the approach I’d generally recommend.

But to answer OP’s question - my supposition was that the mere fact that such a device is even necessary (when compared to docker) is an added work that isn’t obviously easy to implement for someone who is just trying to learn how to containerize their app (and might be a developer but not that experienced with Linux administration) and this one of the main reasons Podman isn’t as popular as Docker.

I think Podman is better in a number of ways, but it isn’t the most intuitive to implement compared to Docker.

It’s not hard. It’s just fiddly.

Especially if you want to go rootless (and you should).

For someone that isn’t “Linux first” (like a baby developer learning to containerize their apps), the idea of dealing with systemd unit files or kublet configs, and having to created dedicated local service accounts (and remembering to enable linger) is somewhat intimidating when compared to just installing docker, whipping up a docker compose file and pressing “start”.

I understand why they’ve taken this approach but it’s pretty clunky and a bit unfriendly.

- https://theintercept.com/2025/01/28/proton-mail-andy-yen-tru... - https://medium.com/@ovenplayer/does-proton-really-support-tr... - https://discuss.privacyguides.net/t/proton-ceo-endorses-trum... - https://tildes.net/~society/1ldg/proton_ceo_tweets_support_f...

There is no ethical consumption under capitalism. I keep along the effort, but it just continues to be impossible.

Did the defense use some sort of tool to debunk? Was it just an obvious deepfake etc? Or was it the officer’s ineptitude that got him caught?

Kafka still wins for very large data pipelines (hundreds of terabytes or petabytes), complex stream processing, or very long retention requirements for messaging.

If you’re mostly streaming messaging between micro-services though (or if you’re currently doing a lot with MQTT) NATS is very likely the better move.

(It’s cool shit)

https://docs.nats.io/