Yes. If you don't need all of the service discovery and auto-scaling shenanigans (or are willing to script it yourself), you can gleefully skip Traefik, Docker Swarm, Kubernetes etc. and just use Caddy! It can really do most things and it does them well.
The documentation split is unfortunate and the GUI really just a status page. The other points are a strength. A pattern that works well: Put all Traefik config in your Docker container definitions, as command line flags and labels, plus the dynamic config provided as a volume. That gives you all the flexibility and only one or two places to look for the config (e.g. a Docker compose file and the dynamic config file)
When done right, I appreciate that Traefik's config design meets the container config/run time split pretty well.
I also get that we're arguing TIMTOWDI vs YAGNI. So, I want to take a beat to say that I think your take is absolutely valid, but I'm coming at this from a place where flexibility isn't my primary concern. I'm usually more interested in tools that will reliably save me time, and that's a quality typically in opposition to flexibility.
For me, any tool that requires or permits multiple configuration planes to get off the ground threatens to be a time sink and a tax for an already packed schedule. This complexity usually requires the operator to absorb a lot of nuance, quirks, and idioms, which is something that's difficult to do quickly. Troubleshooting also grows in scope , again due to the complex design and multiple ways to set things up. Meanwhile, the most inflexible tools in my stack cause me the least trouble due to their simplicity: there's one way to do it, and if it's a common mistake, the answer is easily searched online.
In practice, looking to the Traefik community for support required decoding everyone's different take with varying degrees of CLI and config file involvement, sometimes fragmented across entire discussion threads (not to mention the v1/v2 problem). It made for a very time consuming troubleshooting run - something that would have been avoided by a more simple design like other tools use.
Flexibility sure is one of Traefik's strengths and the CLI arguments seem to be a point of convergence for the more seasoned people on their forums, so that's what I made out to be the happy path. That being said, I think you are spot on that its operation requires awareness of too much nuance and quirks, making it brittle in the long run. I don't get that feeling using Caddy, for example. Also, the "transpilation" problem between everyone's config snippets truly can be a timesink.
If you know what you're doing, XMPP is as secure and more reliable/efficient than Matrix. Really snappy in comparison. Other messengers build on it (Kik for example but also in enterprises). If you're working in security, chances are you're still on XMPP somewhere. That being said, the protocol with its extensions is a bit of a monstrosity, and that also shows in the codebases of available servers. It's no wonder, since XMPP does many things similar to SMTP (federated, based on DNS etc.). I would love if there was a modern, all in one XMPP server written in Go or Rust that includes all the protocol features in a sensible, opinionated package that is straightforward to deploy.. Until then, you'll find me fixing my Prosody instance..
Indeed. Moral depravedness is supposedly modeled by law. There is an uncanny overlap of scammers and normal economic activity though. That needs to change.
