5 ms·

> The main problem with it is that everybody provides example configurations in the nginx config format, so I have to read them, understand them, and translate

by mholt 3y ago

> The main problem with it is that everybody provides example configurations in the nginx config format, so I have to read them, understand them, and translate them. This is so real. I call it "doc-lock" or documentation lock-in. I don't really know a good scalable way to solve this faster than the natural passage of time and growth of the Caddy project.

reactordev 3y ago
LLMs baby! Input nginx config, output caddy config. Input nginx docs, output caddy docs. Someone get on this and go to YC.
- francislavoie 3y ago
  LLMs do a horrendous job with Caddy config as it stands. It doesn't know how to differentiate Caddy v0/1 config from v2 config, so it hallucinates all kinds of completely invalid config. We've seen an uptick of people coming for support on the forums with configs that don't make any sense.
  - eropple 3y ago
    For just blasting a config out, I'm sure there are tons of problems. But (and I have not been to your forums, because...the project just works for me, it's great!) I've had a lot of success having GPT4 do the first-pass translation from nginx to Caddy. It's not perfect, but I do also know how to write a Caddyfile myself, I'm just getting myself out of the line-by-line business.
    - m_sahaf 3y ago
      You could've used the nginx-adapter and skip the faulty LLMs https://github.com/caddyserver/nginx-adapter https://github.com/caddyserver/nginx-adapter
      - eropple 3y ago
        Thanks for the link! Maybe less thanks for the attitude, though--I'm well-versed in how these tools fail and nothing goes out the door without me evaluating it. (And, for my use cases? Generally pretty solid results, with failures being obvious ones that fail in my local and never even get to the deployed dev environment.)
- bklyn11201 3y ago
  You're absolutely right. I'm going to do this today. It's clear from this thread that a) Nginx open source will not proceed at its previous pace, b) the forks are for Russia and not for western companies, and c) Caddy seems like absolutely the most sane and responsive place to move.
deleted 3y ago
[deleted]
CoolCold 3y ago
> This is so real. I call it "doc-lock" or documentation lock-in. I don't really know a good scalable way to solve this faster than the natural passage of time and growth of the Caddy project. I think you are totally right here - gaining critical mass over the time for battle tested solution. On the other hand, the authors [who prefers Caddy] of docs will likely abandon providing Nginx configs sample and someone else will complain on that on HN. "Battle tested" can be seen differently of course, but in my opinion, things like the next one, > IMO most users do require the newer versions because we made critical changes to how key things work and perform. I cannot in good faith recommend running anything but the latest release. from https://news.ycombinator.com/item?id=36055554 https://news.ycombinator.com/item?id=36055554 , by someone working at Caddy doesn't help. May be in their bubble (can I say your bubble as you are from Caddy as well?) noone really cares on LTS stuff and just use "image: caddy:latest" and everything is in containers managed by dev teams - just my projection on why it may be so.

by mholt 3y ago

reactordev 3y ago

LLMs baby! Input nginx config, output caddy config. Input nginx docs, output caddy docs. Someone get on this and go to YC.

francislavoie 3y ago
LLMs do a horrendous job with Caddy config as it stands. It doesn't know how to differentiate Caddy v0/1 config from v2 config, so it hallucinates all kinds of completely invalid config. We've seen an uptick of people coming for support on the forums with configs that don't make any sense.
- eropple 3y ago
  For just blasting a config out, I'm sure there are tons of problems. But (and I have not been to your forums, because...the project just works for me, it's great!) I've had a lot of success having GPT4 do the first-pass translation from nginx to Caddy. It's not perfect, but I do also know how to write a Caddyfile myself, I'm just getting myself out of the line-by-line business.
  - m_sahaf 3y ago
    You could've used the nginx-adapter and skip the faulty LLMs https://github.com/caddyserver/nginx-adapter https://github.com/caddyserver/nginx-adapter
    - eropple 3y ago
      Thanks for the link! Maybe less thanks for the attitude, though--I'm well-versed in how these tools fail and nothing goes out the door without me evaluating it. (And, for my use cases? Generally pretty solid results, with failures being obvious ones that fail in my local and never even get to the deployed dev environment.)
bklyn11201 3y ago
You're absolutely right. I'm going to do this today. It's clear from this thread that a) Nginx open source will not proceed at its previous pace, b) the forks are for Russia and not for western companies, and c) Caddy seems like absolutely the most sane and responsive place to move.

deleted 3y ago

[deleted]

CoolCold 3y ago

> This is so real. I call it "doc-lock" or documentation lock-in. I don't really know a good scalable way to solve this faster than the natural passage of time and growth of the Caddy project. I think you are totally right here - gaining critical mass over the time for battle tested solution. On the other hand, the authors [who prefers Caddy] of docs will likely abandon providing Nginx configs sample and someone else will complain on that on HN. "Battle tested" can be seen differently of course, but in my opinion, things like the next one, > IMO most users do require the newer versions because we made critical changes to how key things work and perform. I cannot in good faith recommend running anything but the latest release. from https://news.ycombinator.com/item?id=36055554 https://news.ycombinator.com/item?id=36055554 , by someone working at Caddy doesn't help. May be in their bubble (can I say your bubble as you are from Caddy as well?) noone really cares on LTS stuff and just use "image: caddy:latest" and everything is in containers managed by dev teams - just my projection on why it may be so.