What I don't see mentioned here or in the article:

PostNord Denmark has been operating with massive losses for a while now, in part because they were required by law to be able to deliver everywhere in Denmark, when there were very little demand for it. The money just isn't there, which is why the law has been changed.

The cost of sending a letter was also just going up and up. In 2025, it cost $4.55 _per letter_.

Denmark is tiny though? Why does it cost $5 per letter?

> I wish Docker Swarm survived.

I heard good things about Nomad (albeit from before Hashicorp changed their licenses): https://developer.hashicorp.com/nomad

I got the impression it was like a smaller, more opinionated k8s. Like a mix between Docker Swarm and k8s.

It's rare that I see it mentioned though, so I'm not sure how big the community is.

I’d wager that like half the teams (at least) using kubernetes today should be using Nomad instead. Like the team I’m on now where I’m literally the only one familiar with Kubernetes and everyone else only has familiarity with more classic EC2-based patterns. Getting someone to even know what Helm does is its own uphill battle. Nomad is a lot more simple. That’s what I like about it a lot.

For better or for worse its a orchestrator (for containers/scripts/jars/baremetal) full stop.

Everything else is composable from the rest of the hashicorp stack consul(service mesh and discovery),vault(secrets) allowing you to use as much/or as little as you need and truly able to scale to a large deployment as needed.

In the plus column , picking up its config/admin is intuitive in a way that helm/k8s never really comes across.

Philosophy wise can put it int the unix way of doing things - it does one thing well and gets out of your way , and you add to it as you need/want. Whereas k8s/heml etc have one way or the high way - leaving you fighting the deployment half the time.

Mitchel Hashimoto was a genius when it came to opinionated design and that was Hashicorp's biggest strength when it was part of their culture.

It's a shame Nomad couldn't overcome the K8s hype-wagon, but either way IBM is destroying everything good about Hashicorp's products and I would proceed with extreme caution deploying any of their stuff net-new right now...

shudders.. `| nindent 12`..

I've been trying to apply CUE to my work, but the tooling just isn't there for much of what I need yet. It also seems really short-sighted that it is implemented in Go which is notoriously bad for embedding.

> seems really short-sighted that it is implemented in Go

CUE was a fork of the Go compiler (Marcel was on the Go team at the time and wanted to reuse much of the infra within the codebase)

Also, so much of the k8s ecosystem is in Go that it was a natural choice.

> CUE was a fork of the Go compiler (Marcel was on the Go team at the time and wanted to reuse much of the infra within the codebase)

Ah, that makes sense, I guess. I also get the feeling that the language itself is still under very active development, so until 1.0 is released I don't think it matters too much what it's implemented in.

> Also, so much of the k8s ecosystem is in Go that it was a natural choice.

That might turn out to be a costly decision, imho. I wanted to use CUE to manage a repository of schema definitions, and from these I wanted to generate other formats, such as JSON schemas, with constraints hopefully taken from the high-level CUE.

I figured I'd try and hack something together, but it was a complete non-starter since I don't work within the Go ecosystem.

Projects like the cue language live and breathe from an active community with related tooling, so the decision still really boggles my mind.

I'll stay optimistic and hope that once it reaches 1.0, someone will write an implementation that is easily embedded for my use-cases. I won't hold my breath though, since the scope is getting quite big.

Why don't you work with the Go ecosystem? You don't use K8s, terraform, etc? What ecosystem do you prefer?

what language would you have chosen?

> I wanted to use CUE to manage a repository of schema definitions, and from these I wanted to generate other formats, such as JSON schemas, with constraints hopefully taken from the high-level CUE.

Have you tried a Makefile to run cue? There should be no need to write code to do this

We evaluated CUE, Jsonnet and CDK8s when we wanted to move on from Helm, and ended up using CDK8s. It's proven to be a good pick so far, it's in Typescript.

Back when my job involved using Kubernetes and Helm, the solution I found was to use `| toJson` instead: it generates one line that happens to be valid YAML as well.

Both Jsonnet and CUE are implemented in Go which happens to be the language Helm is written in. While I agree that it reduces "general embedability" it's ripe fruit for Helm to integrate either or both of these as alternatives to YAML templating.

Holos[1] is an interesting project I’ve been looking at trying out.

1. https://holos.run/

I've looked at Holos recently

1. it seems like development has largely ceased since Sept

2. it looks to only handle helm, not terraform, I'm looking for something to unify both and deal with dependencies between charts (another thing helm is terrible at)

cue and argocd here. it is pretty neat.

the tf is still in hcl form for now.

> At the same time, it struggles with RAM usage when handling even 1TB of data, and presumably ptar has better scaling at that size.

There's also rustic, which supposedly is optimized for memory: https://rustic.cli.rs/docs/

The AI hardware race is still going strong, but with so many rapid changes to the fundamental architectures, it doesn't make sense to bet everything on specialized hardware just yet.. It's happening, but it's expensive and slow.

There's just not enough capacity to build memory fast enough right now. Everyone needs the biggest and fastest modules they can get, since it directly impacts the performance of the models.

There's still a lot of happening to improve memory, like the latest Titans paper: https://arxiv.org/abs/2501.00663

So I think until a breakthrough happens or the fabs catch up, it'll be this painful race to build more datacenters.

That's when you go a level deeper and have every template use another template (e.g. a Helm subchart or Helm library) only to realize scoping and templating is completely fucked in Helm.

I've wanted to make something like this myself, so thanks and good job!

How does this work? Does it rely on GPT to extract the data or does it actually generate a bunch of selectors? If it's the former, then the results aren't reliable since it can just hallucinate whole results or even just parts.

It uses GPT to extract the data: https://github.com/fetchfox/fetchfox/blob/public/src/lib/scr...

I haven't put together a good test framework yet, but qualitatively, the results are surprisingly good, and hallucinations are fairly low. The prompt tells GPT to say (not available) if needed, which helps.

I'm going to try the "generate selectors" approach as well. If you'd like to learn more or discuss just reach out via email ([email protected]) or discord (https://discord.gg/mM54bwdu59 @ortutay)

And they would've found it, because it wouldn't be hidden.

Just put them on a train during work hours! We have really good coverage here but there's congestion and frequent random dropouts, and a lot of apps just don't plan for that at all.

Agreed. Generally just avoid jargon when you aren't sure the reader knows the lingo.