(I'm a big podman stan)

Last I tried using the .kube files I ran into issues with specifying container networks (https://github.com/containers/podman/issues/12965).

This is sort of "fixed" by using a Quadlet ".kube" but IMO that's a pretty weak solution and removes the "here's your compose file, run it" aspect.

Recently (now that Deb13 is out with Podman 5) I have started transitioning to Podmans Quadlet files which have been quite smooth so far. As you say, its great to run things without all the overhead of kubernetes.

▲ zamalek 4 days ago | parent | next [-]

(I'm a bigger podman stan)

I agree about quadlets, amazing.

Docker has one of the most severe cases of not-invented-here. All solutions require a combination of a new DSL, a new protocol, a new encryption scheme, a new daemon, or any combination there-of. People are sleeping on using buildah directly; which OP alluded to with Bakah (but fell short of just using it directly).

Ever wish you could run multiple commands in a single layer? Buildah lets you do that. Ever wish you could loop or some other branching in a dockerfile? Buildah lets you do that. Why? Because they didn't invent something new, and so the equivalent of a dockerfile in buildah is just a script in whatever scripting language you want (probably sh, though).

This will probably give you the general idea: https://www.mankier.com/1/buildah-from

I came across this when struggling and repeatedly failing to get multi-arch containers built in Circle CI a few gears ago. You don't have access to an arm64 docker context on their x86 machines, so you are forced to orchestrate that manually (unless your arm64 build is fast enough under qemu). Things begin to rapidly fall apart once you are off of the blessed Docker happy path because of their NIH obsession. That's when I discovered buildah and it made the whole thing a cinch.

▲

moondev 4 days ago | parent | next [-]

Buildah is elite tooling. Enables you to build with devices and caps and kernel modules. Buildx acts like you should sign a waiver and really weak documentation if at all for what you are trying to do

▲

lttlrck 3 days ago | parent | prev | next [-]

multiple commands in a layer is possible in a dockerfile for a long time, since format 1.4(?) using heredoc, which is just a script netting you loop and branches etc.

▲

mardifoufs 4 days ago | parent | prev | next [-]

Isn't buildah and podman themselves a case of NIH too? ;) I mean, they work fine but I don't think that's an issue with docker either.

	▲	paulddraper 4 days ago \| parent [-]
		How so? What could they have reused instead of inventing?

▲

tracker1 4 days ago | parent | prev [-]

on the QEMU thing... the only time I tried to cross-build arm containers from an x86 server was using whatever servers Github Actions supports... the x86_64 build was pretty normal for the project, but the qemu/buildx/arm64 build was about the same speed as an 8mb Raspberry Pi 4 to build the same project... pretty disappointing.

▲ teekert 4 days ago | parent | prev [-]

"...removes the "here's your compose file, run it"

Claude recently hallucinated this for me:

    [Container]
    ComposeService=my-service
    Yaml=/path/to/your/podman-compose.yaml

For a brief moment in time I was happy but then:

Can you really use "ComposeService" in the systemd unit file? I can't find any reference to it

You're absolutely right to question that - I made an error. There is no ComposeService directive in systemd or Quadlet.

It would be a nice best of both worlds...

▲

0points 4 days ago | parent | next [-]

Many moons ago, the concept of chaos monkey [1] was concieved.

A irrational part of deployment, meant to trigger corner cases and improve the product's stability.

Today, people who out-source thinking to a LLM get the chaos monkey for free.

The only problem seems to be that the LLM proponents are ahistoricists.

1: https://en.wikipedia.org/wiki/Chaos_engineering#Chaos_Monkey

▲

tkiolp4 4 days ago | parent | prev [-]

It’s exhausting. As someone who doesn’t work with systemd, I would have a hard time using llms for this topic.

▲

teekert 4 days ago | parent [-]

I do a combi, sometimes even asking the LLM and starting a ddg search in parallel. It speeds me up. Sometimes the LLM is right, sometimes it's not. NP, I'll get it to work. One should never do anything that one does not understand, but I get to the understand faster as I can also ask more in depth follow up questions to the LLM.

	▲	lotharcable 3 days ago \| parent [-]
		For me LLM is just a rubber duck that talks back. It is very stupid and is usually wrong in some meaningful way, but it can help break logjams in my thinking. Giving me clues that might be missing. Sort of like how writing gibberish is sometimes effective for writers to break writer's block. It is also nice for generating boiler plate code for languages that I am not super familiar with. The biggest problems I have with current state of the art LLMs is that errors compound. Meaning that I only really get somewhat useful answers when starting out with the first few questions or the first couple times I ask it to review some code. The longer the session lasts the more la-la land answers I get. It is a game of odds. I expect that with systemd and quadlets it is going to particularly useless because there just isn't that many examples out there. It can only regurgitate what it is trained with so if something isn't widely used and checked into code bases it is trained on then it can't really do anything with it. Which is why it is nice for a lot of common coding tasks, because a lot of code is just same thing tens of thousands people did before for only slightly different contexts and is mostly boilerplate.