I understand that groups generally have one DM and 4 players, do if you include player options you might sell 5 books instead of one. But that's the shallow, cash-in-now-fuck-next-decade mentality.
Meanwhile they haven't put out a decent adventure in a decade. The internet is awash with people trying to glue their ramblings back into coherent campaigns and running D&D (always a huge time sink) is becoming a worse experience every year as they keep flooding the market with crap.
I love running games but I've come to the point where I'm not really interested in starting a D&D group anymore because of all the bullshit.
WOTC: support your DMs or die.
I've found k8s more manageable with straight manifests, or tooling to generate the manifests from some other source.
I do need to give jsonnet a hard look, as I hear it's less crazy than yaml+templates
[1] https://github.com/companyinfo/helm-charts/tree/main/charts/...
I haven't submitted the WSL2 issue to the Podman team yet. If you get to it before I do, can you link it here?
I've worked around the features bug by just using `devbox generate devcontainer` then adding all my desired container apps and services inside a `devbox.json` file.
[1] https://github.com/containers/podman/issues/18691#issuecomme...
I'm curious now -- are there any other alternatives with similar philosophy/benefits?
Some of the short-list of differences: we use YAML for our configuration language, Dagger can use full-fat languages to define its pipelines. Our feature scope is broader: you can use us to vend IDP-like stacks to your developers if you're a Platform Team; we make development with remote Kubernetes clusters very easy, including all the remote image builds; and we have a number of integrations so you can bring your IaC tool of choice (Pulumi, Terraform) into your pipeline and set up service -> infra dependencies.
which is conveniently packaged in a GH-a-like system by:
https://gitea.com/gitea/act_runner
in
I made an irreverent short on why your CI pipelines ought to be portable and runnable locally. Number one reason? Give your developers their time (and sanity) back. Pushing to Git in the inner loop disrupts flow and shatters attention.
I can check on it whenever I get started on the mini and X versions.
There are many pipelines you can't run locally, because they're production, for example, but there's no reason why we can't capture these workflows to run them locally at less-critical stages of development. Garden offers portable pipelines and then adds caching across your entire web of dependencies. Some of our customers see 80% or higher reductions in run times plus devs get that immediate feedback on what tests are failing or passing without pushing to git first using our Garden Workflows.
We're OSS. [2]