Depends on how tied you are to Linux, but yes it might be worth it. I for one enjoy FreeBSD a lot. I run it on my servers and on one of my laptops. My desktop runs Linux.
If you have the time and motivation I’d say give FreeBSD a shot. Rent a VPS from Vultr for example or install it in a VM on your computer. Play around with it and see how you like it.
- The developers dislike packaging because it makes “plugins” unavailable. Personally I think they are concerned about this for no reason. There ought to be a version of Caddy in the package repos without additional “plugins” that covers the 99% use-case which is to serve static files from a directory with automatic Let’s Encrypt certificate retrieval. Just like how the package on FreeBSD does. Those wanting customization can build from source; that is very reasonable and in line with the expectations one should have to an OS-provided package manager IMO.
- They don’t want to deal with packaging until they hit v1.0.
- They are talking about wanting to package an auto-updater. This is absolutely the wrong approach IMO, but it relates back to their differing in opinion about the role of their “plugins” in relation to the packages that would be provided. I think Debian for example have the same view as me on this issue, and I think other distros do as well probably. Packages provided by the OS-provided package manager should never rely on needing to retrieve additional files not included in the package, except via dependency on other packages, or where they are forced to do so for licensing reasons.
- Speaking of Debian, they mentioned that packaging software written in Go can be problematic/difficult in relation to the Debian packaging guidelines because it seems that to follow those guidelines strictly, each dependency must be packaged separately rather than being vendored. Whether this is correct or not I don’t know.
- Like I said further up ITT, the source is covered by Apache 2.0 and they also confirm in that thread that compiling binaries and distributing binaries you’ve compiled from source is allowed in accordance with those terms. That’s really no surprise — if that was not allowed then they couldn’t have said that the source was covered by Apache 2.0 — but it’s reassuring to see that they intentionally want to allow redistribution of binaries built from source.
It seems to me that if packages for Linux are going to become available any time soon, someone needs to step up and take care of it. For example by providing a PPA for Ubuntu users. There was one PPA mentioned in the thread but I didn’t look into whether it is still maintained or not since I do not have any current plans of running Caddy on Ubuntu myself.
Unfortunately they have no good way of doing that yet. Or, at least, they didn’t back when most of that discussion took place.
From a comment in the thread:
> Go is currently really bad at “runtime” plugins. There are only three strategies I know of that may work:
> 1. Launch separate processes for each plugin and use ipc to communicate. Potentially slow, and a lot could go wrong.
> 2. Some kind of cgo based plugin system that runs dynamicly linked go libs and uses a cgo shim on both sides for compatibility. Introduces build complexity and makes cross-compiling harder.
> 3. Some kind of dynamic language interpreter: there are native go javascript and lua interpreters, but using those for plugins seems pretty crazy,
> Until the go authors implement better support for runtime plugins, I think we are stuck with built-time.
This isn't something easily fixed. Go's big selling point (pros and cons included) is that it generates statically compiled binaries. Go plugins are a complicated problem because of that.
Depends on how tied you are to Linux, but yes it might be worth it. I for one enjoy FreeBSD a lot. I run it on my servers and on one of my laptops. My desktop runs Linux.
If you have the time and motivation I’d say give FreeBSD a shot. Rent a VPS from Vultr for example or install it in a VM on your computer. Play around with it and see how you like it.
As for packaging of Caddy on Linux there seems to be a few issues if you look at the following thread: https://caddy.community/t/packaging-caddy/61
- The developers dislike packaging because it makes “plugins” unavailable. Personally I think they are concerned about this for no reason. There ought to be a version of Caddy in the package repos without additional “plugins” that covers the 99% use-case which is to serve static files from a directory with automatic Let’s Encrypt certificate retrieval. Just like how the package on FreeBSD does. Those wanting customization can build from source; that is very reasonable and in line with the expectations one should have to an OS-provided package manager IMO.
- They don’t want to deal with packaging until they hit v1.0.
- They are talking about wanting to package an auto-updater. This is absolutely the wrong approach IMO, but it relates back to their differing in opinion about the role of their “plugins” in relation to the packages that would be provided. I think Debian for example have the same view as me on this issue, and I think other distros do as well probably. Packages provided by the OS-provided package manager should never rely on needing to retrieve additional files not included in the package, except via dependency on other packages, or where they are forced to do so for licensing reasons.
- Speaking of Debian, they mentioned that packaging software written in Go can be problematic/difficult in relation to the Debian packaging guidelines because it seems that to follow those guidelines strictly, each dependency must be packaged separately rather than being vendored. Whether this is correct or not I don’t know.
- Like I said further up ITT, the source is covered by Apache 2.0 and they also confirm in that thread that compiling binaries and distributing binaries you’ve compiled from source is allowed in accordance with those terms. That’s really no surprise — if that was not allowed then they couldn’t have said that the source was covered by Apache 2.0 — but it’s reassuring to see that they intentionally want to allow redistribution of binaries built from source.
It seems to me that if packages for Linux are going to become available any time soon, someone needs to step up and take care of it. For example by providing a PPA for Ubuntu users. There was one PPA mentioned in the thread but I didn’t look into whether it is still maintained or not since I do not have any current plans of running Caddy on Ubuntu myself.