what if I'm not using CoreOS?
Podman runs on any distro (or more strictly: any distro that uses systemd).
Comment on Quadlets might make me finally stop using docker-compose
thevoiceofra@mander.xyz 1 year ago
Interesting. But what If I’m not using CoreOS? Also RedHat fucked up by using YAML for configuration.
what if I'm not using CoreOS?
Podman runs on any distro (or more strictly: any distro that uses systemd).
…except I can run Docker anywhere. It’s not tied to systemd. These quadlets seem like a very systemd-specific thing. Which is great if you’re building everything around systemd but it’s a niche.
systemd [is] a niche
Maybe in the wider world of all the operating systems installed on all the computers, but for Linux-based computing it is, like it or not, near ubiquitous these days. And in particular for server systems (and this is, after all, /m/selfhosted), good luck finding something that isn't systemd-based unless you're deliberately choosing a BSD or aiming for a system which has ever-decreasing amounts of support available.
This being selfhosted is exactly the reason I would’ve expected people to be aware there’s more variety out there. systemd is not as ubiquitous as you make it sound.
Secondly, tying your containerization solution into your init system is a spectacularly bad idea. You could already do this with docker; the best practice is to not do it. You have a restart policy built into docker/podman for a reason. Let the init system deal with podman/docker itself, and let podman/docker manage their containers.
Third, the article title is misleading; if anything it should say quadlets made them give up podman-compose, not docker-compose.
It’s built into Podman 4.x, so you can easily install it on any distro (with Systemd).
kylian0087@lemmy.world 1 year ago
What is wrong with YAML for configuration? It is much more easy to read then say json.
anyhow2503@lemmy.world 1 year ago
YAML is way too bloated of a standard and has a ton of inconsistencies between implementations, despite the widespread reputation of simplicity. It is easy to read as long as you limit yourself to a fraction of its capabilities and err on the side of caution when it comes to escaping characters (especially when number literals are involved, or booleans for that matter). As far as alternatives go, I prefer TOML for simple key=value configs, but it has its own issued and is nowhere near as featureful, for better or worse.
brian@programming.dev 1 year ago
There is some surprising behavior with some of the features of yaml, mostly arising from the fact that it looks nice to read. Here’s a list of things that you can avoid to avoid a lot of the pitfalls: hitchdev.com/strictyaml/why/ . I haven’t actually used strictyaml, but the arguments it presents are pretty solid and some are things I’ve run into in real environments
thevoiceofra@mander.xyz 1 year ago
If you’re just reading configs then yeah, it’s superior. If you’re maintaining big complex configurations you need something to reduce boilerplate. Jsonnet, nickel or nix are excellent here. So you’re forced to use one of those, generate yaml, and deploy. One more moving thing in your pipeline which can break.
sasoiliev@lemmy.world 1 year ago
JSON was never meant for configuration.
YAML has a ton of footguns.