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).
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.
And that's great, it's just not exciting because the future is linux based, if just for the hardware support. I was hoping for a truenas fork for people annoyed with the truenas closed source/hostility stuff as of late.
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)
The trick is to combine it all, which is what MS is doing. For example your MS account stores any GDIDs that you've logged in with.
If you use a different identifier to track changes in a GDID/machine-id/etc., that means you can continue tracking using mainly just the new machine-id, but you should always keep trying to correlate it with other things in case it changes.
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)
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.
It's not just mildly annoying, it completely ruins a great thing.
Docker Compose is to stacks what Dockerfiles are to a single application. Podmans solution is to not commit to compose, but instead to create a bespoke mechanism involving a bunch of tiny files, all of which is insanely system (linux) specific, and therefore completely non-portable.
I genuinely don't understand how someone can see the value of Docker, but then do things so completely "not-docker" when it comes to deployment/stacks/orchestration.
> but instead to create a bespoke mechanism involving a bunch of tiny files, all of which is insanely system (linux) specific, and therefore completely non-portable.
To nit pick slightly, it's not really a bespoke mechanism it's just re-using the mechanisms provided by systemd. Quadlets are implemented as a systemd generator in order to re-use the existing service management system that exists on essentially all major Linux distros. Quadlets are less a direct competitor with compose (hence why Podman implements the compose spec) and more a way to better integrate containers with the rest of a system. The closer Podman native equivalent to compose is Kube files.
It can be argued that it’s Docker that is reinventing the wheel and doing its own bespoke process management, journal management etc when all of these are solved problems on Linux. Podman is instead reusing the platform which exists, Quadlets are just reusing systemd, so as a sysadmin I can manage, control and monitor docker containers using the same standard tooling that I already use to manage, control and monitor all the other processes which are running on the system.
Architecturally I find the above argument attractive. The problem is chronology. Docker and docker compose came before systems was ubiquitous and long before Quadlets, so it’s natural to think of Quadlets as reinventing the wheel.
Personally I wish docker had not rejected composition/integration around systemd. Would have made everyone’s job a lot easier in the long term.
> Personally I wish docker had not rejected composition/integration around systemd. Would have made everyone’s job a lot easier in the long term.
It also would have only run on Linux hosts (and not all of those at that), so something else would have been adopted instead. Docker didn't win by being superior to every alternative, it won by being good enough and being everywhere. For portable orchestration, Desktop does ship with kubernetes that's literally one click to enable.
> Docker Compose is to stacks what Dockerfiles are to a single application. Podmans solution is to not commit to compose
This isn't (completely) true. I found podman-compose to be a more or less drop-in replacement for docker-compose. I know that in the past support was patchy, but things are rather good now.
Pretty sure that's because podman-compose literally calls docker-compose under the hood.
e: from the manpage:
"podman compose is a thin wrapper around an external compose provider such as docker-compose or podman-compose. This means that podman compose is executing another tool that implements the compose functionality but sets up the environment in a way to let the compose provider communicate transparently with the local Podman socket. The specified options as well as the command and argument are passed directly to the compose provider."
That's the "podman compose" wrapper command. podman-compose (the implementation referenced in the first sentence of your quote) does not call docker-compose: https://github.com/containers/podman-compose
FWIW, for me docker compose works just fine with podman. I am not sure what kind of additional configuration is needed these days, make sure you are running podman with the socket thing and perhaps set DOCKER_HOST. It's just a client / frontend to an API that podman provides.
IIRC `podman compose` can invoke either `podman-compose` or `docker-compose` and sets up the environment for the call, so I don't think you need to even really do anything special other than install either of the 2 commands
The purpose of quadlets is when you want good integration with systemd.
The better equivalent of docker compose is podman kube, which does use a single file. And it isn't bespoke, it uses the same format as kunernetes.
And if you prefer the docker compose format, podman-compose is available as a separate tool.
And FWIW docker compose is a separate tool from docker itself as well (and needs to be installed separately on several linux distros). And can actually work with podman instead of docker.
> the idea of dealing with systemd unit files or kublet configs, and having to created dedicated local service accounts
Podman does not require systemd (thank God). I use a simple podman compose up/down in a user systemd file to automatically bring my containers up at boot, but other mechanisms are possible, like quadlets and init scripts.
Quadlets are awesome and honestly I think one of the best additive things that podman has on top of the regular docker toolset.
I use podman regularly, and despite it being a good drop-in replacement like 95% of the time, the 5% of the time where it isn't seamless are super painful. For example, skaffold (https://skaffold.dev/) pukes all over itself when you try to run podman as a drop in replacement. I'm sure there are plenty of other examples, but that one stops me from using podman at work in addition to in my personal projects.
Well, but that's kinda the point, isn't it? You know that other mechanisms are possible, but you opted out for a user systemd file. I know that too, and I also just use systemd for that. Because the alternative doesn't look much easier. I guess it makes sense that they try to discourage it now, because for serious deployment it isn't the best option. But when I install Podman on my laptop, I really wish the systemd configs would be added automatically without me even knowing.
I mean, really, if we keep in mind that formally these are 2 totally unrelated projects, it's hard to complain. Yes, it's almost seamless. But since when installing Podman everyone thinks roughly "I am installing a newer better Docker version", and we all already have a few dozens of custom Docker containers running, it's hard no to wish it was even more seamless and backwards-compatible. I remember the transition process wasn't nearly as smooth as I hoped, and every small glitch is kinda stressful, because you know that currently all of it "somehow works", and if something breaks you probably won't even notice right away.
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.
You could quite simply have a systemd file that calls podman compose up when the service starts and podman compose down when it stops. Basically the same systemd file for every container stack defined in a single compose.yml. It's extremely easy, and does not do stuff behind your back like Docker (such as silently altering iptables rules).
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.
I think it's just because Docker came before. Podman is more secure and architecturally cleaner, but not touching something that works is an equally good reason not to migrate.
It might not be the popular way here in HN but nowadays I just ask llm to create required configuration files and everything is so easy. Of course you need to review them but tbh no more headaches at least with config files.
> 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.
Or, to look at it another way, the answer is that it’s the developers who don’t want to learn something new that, objectively speaking, might turn out to be better than what they’re used to.
Their free terms are kind of bad. They use CORS security feature to block you from loading content from other sites. It doesn't cost them anything to let your site link outside content so they are only doing it make the free tier bad so people upgrade.
I don't think it's a coincidence that supporters of positions that are broadly considered extremist in their respective countries are also the ones who end up running services like private VPN and email.
Yeah - answered below. As I mentioned, a lot of the tweets and Reddit posts have been deleted so it’s hard to track down now. It was a bit of a shitstorm on Mastodon some months ago though.
There have been many shitstorms, but whenever I looked at the actual tweets or sources, there was not much actual evidence. More often it showed the founder being a poor communicator, but not right-wing.
I also think that there's significant overlap in the venn diagram of "I want to provide a privacy service" and "I hold some right wing views." If you're launching a no-logs VPN service, you probably have some distrust of institutions, lean closer toward techno-libertarian views which are increasingly getting absorbed into the right, have some form of belief in a free market, which is also starting to become a center/center-right view as the left is seeking a post-capitalist society that may or may not have a free market. The modern left is also unfortunately inching closer and closer to wanting nanny state style policies, so it's not surprising to see right wing views among privacy tech CEOs.
For left wing VPNs there's riseup, but it's not the same category of product as Mullvad, it's a free giveaway that you have to request access to, and intended for your personal use only - no excessive bandwidth like torrenting.
Yeah. It’s trace now because many of the tweets and Reddit posts have since been (unsurprisingly) purged but it looks basically the same as what we’re discussing regarding Mullvad right now.
reply