|
|
|
|
|
|
by mariusor
1371 days ago
|
|
|
I think that if you have a toolchain as easy to bring up and use as Go's, and the stance towards dynamic libraries that Go has, it's understandable that plugins come with the downside of recompiling. It's a chore for sure, but if Caddy is an important part of your infrastructure, having a node that compiles static versions of it for your specific use is not too much of a change from repackaging a docker container with your specific configuration of nginx. |
|
|
Under the limitation of "no dynamic loading anywhere ever", Caddy has indeed made it exceptionally easy (with xcaddy and their web builder) to compile with modules, but this doesn't excuse the fact that their purely philosophical stance is making the job of sysadmins harder. I've heard decent arguments against dynamic libraries (although IMO they still didn't outweigh the downsides of static linking), but never against dynamic loading in general.
Is there a good explanation of this stance anywhere? I haven't spent too much time looking, I'll admit, but if you're breaking decades of common practice, you better put that explanation front and center.
> having a node that compiles static versions of it for your specific use is not too much of a change from repackaging a docker container with your specific configuration of nginx
Sure, but a custom Docker container isn't the baseline for ease of use, `apt-get install [module] && a2enmod [module]` is.