3 ms·

> [...] consider using caddy[1]. It's a HTTP/2 web server written in Go To be fair, it's not. It simply wraps Go's HTTP/2 server which is mostly developed by B

by tagrun 10y ago

> [...] consider using caddy[1]. It's a HTTP/2 web server written in Go To be fair, it's not. It simply wraps Go's HTTP/2 server which is mostly developed by Brad Fitzpatrick, which in turn relies on Go's crypto libraries (written in Go and assembly). As a Go user, I personally don't see any point in using Caddy, as I prefer writing a few hundred lines of Go to serve static pages with all the features I need, with the additional ability of serving more than static pages (you can do fastcgi with Go's stdlib if you need it, I personally prefer writing server code in Go). This is especially true considering that they called their non-paying users dishonest, for not "honestly paying back the value it provides you" while at the same time not sharing a single cent of their revenues with Google who develops the actual HTTP server they wrap (or with any other third party libraries that "provide value" to them). (old discussion: https://news.ycombinator.com/item?id=11264041 https://news.ycombinator.com/item?id=11264041)

pfg 10y ago
> To be fair, it's not. It simply wraps Go's HTTP/2 server which is mostly developed by Brad Fitzpatrick, which in turn relies on Go's crypto libraries (written in Go and assembly). I don't think that's a fair description of Caddy. Of course they're going to use the existing packages in Go, why would they reinvent the wheel? Caddy provides useful things like a config syntax, middleware, automatic certificate deployment, etc. which you'd have to reimplement or take from somewhere else. > As a Go user, I personally don't see any point in using Caddy, as I prefer writing a few hundred lines of Go to serve static pages with all the features I need, with the additional ability of serving more than static pages (you can do fastcgi with Go's stdlib if you need it, I personally prefer writing server code in Go). Caddy allows you to write your own extensions/middleware, which should cover all that. In turn, you get to re-use all the existing extensions and other things Caddy takes care of (which, in my experience, you'd inadvertently end up reinventing at some point anyway). > This is especially true considering that they called their non-paying users dishonest, for not "honestly paying back the value it provides you" while at the same time not sharing a single cent of their revenues with Google who develops the actual HTTP server they wrap (or with any other third party libraries that "provide value" to them). I don't parse that sentence as "you're dishonest if you don't pay for Caddy", but rather "be honest about the value it provided." It's still a free project, and I don't see the problem here at all.
- tagrun 10y ago
  > Caddy provides useful things like a config syntax, middleware, automatic certificate deployment, etc. which you'd have to reimplement or take from somewhere else. Caddy is promoted as an HTTP server. If you focus on that feature rather than the cloud of extra stuff that can make life easier for some (which are orthogonal to what HTTP server does), this is exactly what Caddy does. Sure, I'm not saying they should have written their HTTP server from scratch. But the way they're selling is apparently confusing enough that some people think Caddy developers are actually writing an HTTP server. net/http (and other go libraries) does the real work here, and they sure deserve credit (which they or you don't give in a visible way) if we're going to talk about fairness or paying for honest work. Let's see about those features. You don't need any configuration script syntax when you use net/http directly, you can simply marshall/unmarshall your config struct as a json file. I'm using Let's Encrypt and renewing the certificate is as trivial as running a single bash line. So I still don't see anything I need in actual Caddy code that I need and can't implement easily on my own. > Caddy allows you to write your own extensions/middleware, which should cover all that. In turn, you get to re-use all the existing extensions and other things Caddy takes care of (which, in my experience, you'd inadvertently end up reinventing at some point anyway). Why on earth would I do that when I can write Go directly? This has been discussed many many times, and the community has been clear and loud about web-frameworks in Go. For most, net/http and standard library, maybe with a few libs from gorilla, is the best way to write a server. > I don't parse that sentence as "you're dishonest if you don't pay for Caddy", but rather "be honest about the value it provided." It's still a free project, and I don't see the problem here at all. No, it's not a free project. Not according to them: https://caddyserver.com/blog/is-caddy-free https://caddyserver.com/blog/is-caddy-free No need to weasel around words now, the words have been said. This is not something taken out of context. Go read that whole announcement. Regardless of how and why you want to sugar coat it, that is what they said, that is what they wanted to say. And after criticism, they since removed the word "honestly". To add to the insult, they're not "honest about the value if provided" them in the first place, since they're giving any portion of their income back to Google and other developers (they're using blackfriday etc.). This was their pitch when they called their free users dishonest: > There's no such thing as free software. The question is, "Who pays the price?" Being a FOSS project is something. Telling people is morally wrong using their FOSS project without paying and speaking all high and mighty, while making profits from others' FOSS code and not paying them back a single cent is more than questionable. This is in particular true when it is the 3rd party code (go's stdlib) which does the real work. It's amazing how you claim you're not seeing the gigantic problem here. To summarize, the problem is two-fold: 1) They're morally trying coerce people into paying a software which they chose to publish under Apache License. While this seems contradictory, they're trying to justifying this with: There's no such thing as free software. The question is, "Who pays the price?". 2) Somehow, the moral code they want people to obey doesn't apply to them. This is in particular disturbing if you add the fact that the code which does the heavy-lifting (the actual HTTP server that Caddy uses) is written by a 3rd party, with whom they don't share any of their revenue. Of course, the "Who pays the price?" argument also doesn't apply to other 3rd part code they use to make profits. Both has parallels in the brief and colorful history of Elementary OS: they called their free users cheaters while not paying a single cent to the upstream or to Debian. They tried to weasel their way out by saying "cheating the system" doesn't mean "cheaters"` etc. (akin to your attempt above). But the words had been said, and everyone who read the post knew what they said. People were rightfully upset. They edited their blog post to remove the wording "cheating the system".

by tagrun 10y ago

pfg 10y ago

> To be fair, it's not. It simply wraps Go's HTTP/2 server which is mostly developed by Brad Fitzpatrick, which in turn relies on Go's crypto libraries (written in Go and assembly). I don't think that's a fair description of Caddy. Of course they're going to use the existing packages in Go, why would they reinvent the wheel? Caddy provides useful things like a config syntax, middleware, automatic certificate deployment, etc. which you'd have to reimplement or take from somewhere else. > As a Go user, I personally don't see any point in using Caddy, as I prefer writing a few hundred lines of Go to serve static pages with all the features I need, with the additional ability of serving more than static pages (you can do fastcgi with Go's stdlib if you need it, I personally prefer writing server code in Go). Caddy allows you to write your own extensions/middleware, which should cover all that. In turn, you get to re-use all the existing extensions and other things Caddy takes care of (which, in my experience, you'd inadvertently end up reinventing at some point anyway). > This is especially true considering that they called their non-paying users dishonest, for not "honestly paying back the value it provides you" while at the same time not sharing a single cent of their revenues with Google who develops the actual HTTP server they wrap (or with any other third party libraries that "provide value" to them). I don't parse that sentence as "you're dishonest if you don't pay for Caddy", but rather "be honest about the value it provided." It's still a free project, and I don't see the problem here at all.

tagrun 10y ago
> Caddy provides useful things like a config syntax, middleware, automatic certificate deployment, etc. which you'd have to reimplement or take from somewhere else. Caddy is promoted as an HTTP server. If you focus on that feature rather than the cloud of extra stuff that can make life easier for some (which are orthogonal to what HTTP server does), this is exactly what Caddy does. Sure, I'm not saying they should have written their HTTP server from scratch. But the way they're selling is apparently confusing enough that some people think Caddy developers are actually writing an HTTP server. net/http (and other go libraries) does the real work here, and they sure deserve credit (which they or you don't give in a visible way) if we're going to talk about fairness or paying for honest work. Let's see about those features. You don't need any configuration script syntax when you use net/http directly, you can simply marshall/unmarshall your config struct as a json file. I'm using Let's Encrypt and renewing the certificate is as trivial as running a single bash line. So I still don't see anything I need in actual Caddy code that I need and can't implement easily on my own. > Caddy allows you to write your own extensions/middleware, which should cover all that. In turn, you get to re-use all the existing extensions and other things Caddy takes care of (which, in my experience, you'd inadvertently end up reinventing at some point anyway). Why on earth would I do that when I can write Go directly? This has been discussed many many times, and the community has been clear and loud about web-frameworks in Go. For most, net/http and standard library, maybe with a few libs from gorilla, is the best way to write a server. > I don't parse that sentence as "you're dishonest if you don't pay for Caddy", but rather "be honest about the value it provided." It's still a free project, and I don't see the problem here at all. No, it's not a free project. Not according to them: https://caddyserver.com/blog/is-caddy-free https://caddyserver.com/blog/is-caddy-free No need to weasel around words now, the words have been said. This is not something taken out of context. Go read that whole announcement. Regardless of how and why you want to sugar coat it, that is what they said, that is what they wanted to say. And after criticism, they since removed the word "honestly". To add to the insult, they're not "honest about the value if provided" them in the first place, since they're giving any portion of their income back to Google and other developers (they're using blackfriday etc.). This was their pitch when they called their free users dishonest: > There's no such thing as free software. The question is, "Who pays the price?" Being a FOSS project is something. Telling people is morally wrong using their FOSS project without paying and speaking all high and mighty, while making profits from others' FOSS code and not paying them back a single cent is more than questionable. This is in particular true when it is the 3rd party code (go's stdlib) which does the real work. It's amazing how you claim you're not seeing the gigantic problem here. To summarize, the problem is two-fold: 1) They're morally trying coerce people into paying a software which they chose to publish under Apache License. While this seems contradictory, they're trying to justifying this with: There's no such thing as free software. The question is, "Who pays the price?". 2) Somehow, the moral code they want people to obey doesn't apply to them. This is in particular disturbing if you add the fact that the code which does the heavy-lifting (the actual HTTP server that Caddy uses) is written by a 3rd party, with whom they don't share any of their revenue. Of course, the "Who pays the price?" argument also doesn't apply to other 3rd part code they use to make profits. Both has parallels in the brief and colorful history of Elementary OS: they called their free users cheaters while not paying a single cent to the upstream or to Debian. They tried to weasel their way out by saying "cheating the system" doesn't mean "cheaters"` etc. (akin to your attempt above). But the words had been said, and everyone who read the post knew what they said. People were rightfully upset. They edited their blog post to remove the wording "cheating the system".