sudonem

There are a couple of things going on here.

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.

It’s because those codecs require SDK’s that are expensive to license. That’s not a Linux specific issue - it’s always been that way for the non-studio version of Resolve (with some exceptions on MacOS since the ProRes codecs are already part of the OS).

The BSD base is the entire point.

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.

This is what I do. Works fine.

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)

As much as I want this to be true, tech not being socially acceptable has not been much of a barrier in the past. At least not in the US.

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

Some people perhaps just don’t want to give money to literal Bond villains. ¯\_(ツ)_/¯

And it’s easily altered.

Except for the part where Oracle is so deeply embedded into the US government, and Larry Ellison is connected enough that they will be granted any and all bailouts necessary to prevent this (while everyone pretends not to notice that such bailouts are socialism)

Sure. But that wasn’t OP’s question.

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.

> Doesn't quadlet fix some or all of those problems?

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.

Linux. It’s not the installation of podman that can be fiddly. It’s the setting up systemd unit files and local user accounts for rootless / daemonless deployment of containerized apps that can be a headache.

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

I’d wager it’s mainly just that deployment is mildly more annoying and requires more disparate steps.

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.

TIL. Nice.

We should probably just bring back Geocities at this point.

True enough. Although has Andy Yang openly supported Donald Trump so…. That’s a no for me.