41–50 of 212 posts
To me, this big problem with Docker is that it does a ton of changes to my system, even when I don't use it. It runs a daemon, it uses a bunch of IPs, it mounts a ton of stuff ... Is there a reason for all that noise and complexity? There can't be a reason until I run a container, right? And even then, it seems way too much. Is it different when using Quadlets?
Earlier quoted context omitted.
It's not type safe.
> It's not type safe. I fail to see what leads you to believe this is a relevant point when discussing INI files as the alternative to YAML.
Earlier quoted context omitted.
> The original Quadlet repository describes Quadlet this way: > What do you get if you squash a Kubernetes kubelet? > A quadlet So it's based on reinterpreting the root "kuber-" which ultimately means something"to do with "turn", as "cube", and then metaphorically reducing a cube to a square.
I thought it was half a K8s.
Earlier quoted context omitted.
I thought it was half a K8s.
They squashed kubelet, not K8s. By that, they probably mean that they got rid of the kubelet and delegated its functionality to systemd (which is already there besides the kubelet if the node uses systemd based distro). Note that quadlet is also capable of creating services based on K8s manifest.
I used a very similar approach in the (now EOL'ed, gonna be replaced by full K8s) infra at $DAYJOB. My main reason to stick with docker-compose is because developers are familiar with it and can then easily patch/modify the thing themselves. Replacing with something systemd will add a dependency over the people that know systemd (which are not usually application developers in your average HTTP API shop)
To me, this big problem with Docker is that it does a ton of changes to my system, even when I don't use it. It runs a daemon, it uses a bunch of IPs, it mounts a ton of stuff ... Is there a reason for all that noise and complexity? There can't be a reason until I run a container, right? And even then, it seems way too much. Is it different when using Quadlets?
Nitpick you wonder why yaml is preferred to ini files when it is lined up to each other.
INI files are not specified anywhere, so it ends up being a implementation-defined free-for-all. Also, YAML supports data structures that INI files don't. I don't understand the hate that YAML gets. If you're not tasked with writing a parser, the data format just works as expected.
NI: Nicaragua
NL: Netherlands
NO: Norway
python: 3.2.3
numpy: 2.1
octal: 042
Earlier quoted context omitted.
What? If you use containers this simplifies the stack rather than complicating it. Instead of kubernetes and other popular tools it's just rootless podman and systemd which is already there. I'm using a similar setup and this excites me. It's too new to be in my repository but as soon as I get an extra hour I'll compile it and take it for a spin.
If you want to really simplify using containers, you could just use systemd-nspawn.
But I'll look into nspawn could be useful.
Earlier quoted context omitted.
> It's not type safe. I fail to see what leads you to believe this is a relevant point when discussing INI files as the alternative to YAML.
Yaml coerces values (the string "on" is coerced to bool true for example), with ini you do any conversion from strings yourself
INI isn't specified, thus you cannot claim that the INI format does something a certain way.
The best shot at a specified INI file format might be TOML, and even that format is subjected to the same type of criticism.
Earlier quoted context omitted.
I also miss the simplicity of compose, but for me running rootless is worth the tradeoff. It also forced me to rethink how I used containers and I realized many times a simple podman_run.sh is enough. It also helped me understand containers better because there was less magic going on, sometimes limitations can be good.
> I also miss the simplicity of compose, but for me running rootless is worth the tradeoff. To setup/tear down software dev environments deployed locally, the root/rootless discussion isn't really relevant. Ease of deployment and ease of use are critical though, and Docker is above all a development experience victory.
Podman-compose isn't as good as docker but it exists, and you can run docker-compose with podman as the runtime. I don't need it as my environments are simple and even wrapping the commands in shell scripts would be overkill. But the option is there.