Serve2d – A protocol detecting server
github.com
Serve2d – A protocol detecting server
1–10 of 77 posts
Re: Serve2d – A protocol detecting server
#2Or use the good old sslh: http://www.rutschle.net/tech/sslh.shtml
Re: Serve2d – A protocol detecting server
#3Or use the good old sslh: http://www.rutschle.net/tech/sslh.shtml
That is certainly part of the inspiration and legacy behind serve2d.
This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)
Re: Serve2d – A protocol detecting server
#4Or use the good old sslh: http://www.rutschle.net/tech/sslh.shtml
That is certainly part of the inspiration and legacy behind serve2d. This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)
So here's what hopefully won't be considered a trolling question: I have seen a lot of "100% Go" projects over the past several years and that's usually presented as a big feature. Some pretty trivial things have been redone as brand new in Go, and then suddenly gain lots of attention. What is so magical about a project written in Go vs C, Python, Ruby, Rust, JS, etc.? As a user of the software I won't care what it's written in, if it's done well. If it's done poorly, I am much more likely to look for better alternatives than to fix it (if only I had about 240 hours in a day...), so what's the advantage?
To me, an advantage in usability is having a PPA with properly built .deb packages. If I have to use a language-specific package manager that I don't already use regularly, you've likely lost me, unless I really need this functionality. If it doesn't come with a proper daemon mode (correct forking, PID file support, proper file or syslog logging), sample config file, man page, or an init file, that's even worse. I am much less likely to use this in any type of "production" environment if I have to maintain those pieces myself. Running things in a screen session is so "I'm running a Minecraft server".
That is not to criticize your work. You've done a great job! serve2d looks very interesting and I might actually have to give it a try sometime.
Re: Serve2d – A protocol detecting server
#5Or use the good old sslh: http://www.rutschle.net/tech/sslh.shtml
That is certainly part of the inspiration and legacy behind serve2d. This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)
”This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)”
Great! This seems to be a very good Selling Point for go!
Re: Serve2d – A protocol detecting server
#6Is possible to for MySQL ?
Re: Serve2d – A protocol detecting server
#7We did something similar in our Tarantella product many years ago. However we quickly discovered that many companies operate network infrastructure that verifies protocols. For example they would check that whatever happened on port 443 was valid SSL and nothing else.
In the end we modified our clients to include a decoy cipher suite in the SSL negotiation. That kept the network happy, and was enough for our multiplexer to then internally route to the correct backend.
Re: Serve2d – A protocol detecting server
#8Earlier quoted context omitted.
That is certainly part of the inspiration and legacy behind serve2d. This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)
So here's what hopefully won't be considered a trolling question: I have seen a lot of "100% Go" projects over the past several years and that's usually presented as a big feature. Some pretty trivial things have been redone as brand new in Go, and then suddenly gain lots of attention. What is so magical about a project written in Go vs C, Python, Ruby, Rust, JS, etc.? As a user of the software I won't care what it's…
Go produces a single static binary. Consequently deploying go apps is as simple as copying a single file around, that just works.
Re: Serve2d – A protocol detecting server
#9Earlier quoted context omitted.
So here's what hopefully won't be considered a trolling question: I have seen a lot of "100% Go" projects over the past several years and that's usually presented as a big feature. Some pretty trivial things have been redone as brand new in Go, and then suddenly gain lots of attention. What is so magical about a project written in Go vs C, Python, Ruby, Rust, JS, etc.? As a user of the software I won't care what it's…
Go produces a single static binary. Consequently deploying go apps is as simple as copying a single file around, that just works.
As I alluded to below, the power of this feature should probably not be underestimated.
Re: Serve2d – A protocol detecting server
#10Earlier quoted context omitted.
That is certainly part of the inspiration and legacy behind serve2d. This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)
So here's what hopefully won't be considered a trolling question: I have seen a lot of "100% Go" projects over the past several years and that's usually presented as a big feature. Some pretty trivial things have been redone as brand new in Go, and then suddenly gain lots of attention. What is so magical about a project written in Go vs C, Python, Ruby, Rust, JS, etc.? As a user of the software I won't care what it's…
The number 1 selling point of something written in Go is that it's much easier to package. The result of a compilation is a standalone binary that can be copy-pasted everywhere, as long as the architecture matches what was input at compilation time. This means:
- no more having to deal with dependencies at packaging time, which makes packagers' job simpler because all they have to care is the one and only standard way to retrieve dependencies and build the binary. (Much like the standard way of doing things in C would be ./configure && make && make install, with the added bonus point that the dependencies are also taken into account). This also means that there's a higher chance that the software will be packaged in the distribution of your choice, because the bar is lower
- no more having to deal with dependencies at runtime, because each binary has everything it needs inside of itself. In practice this means "scp as a deploying method". It's an even lower common denominator than packages.
> If it doesn't come with a proper daemon mode (correct forking, PID file support, proper file or syslog logging), sample config file, man page, or an init file, that's even worse.
This is orthogonal to the choice of programming language, though. On top of that, I believe the application shouldn't deal with forking, it's the job of your supervision system to deal with daemons. All an application has to do is log whatever happens on STDERR and let the system handle that.