61–70 of 77 posts
Why? The entire point of ports is so you don't have to do this. Don't get me wrong, it's kinda cool, but it seems like a really bad idea to actually do it.
Earlier 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 has advantage over scripting in speed, over C/C++ in memory management, over strict FP languages in popularity, and over Rust in being stable and known for longer.
Earlier quoted context omitted.
Nothing stops you from passing a VPN through a TCP connection on port 80 and 443. There are few protocols people haven't tunnelled IP over (DNS included...)
I often have to work behind "smoothwall". AFAIK, it only allows HTTP over port 80 and HTTPS on port 443 - any other protocol on any other port gets blocked, including other protocols over port 80/443. To bypass this, I wrote a simple ruby script to tunnel TCP connections, while adding fake HTTP headers to get through the firewall.
Earlier 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…
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 wa…
As for logging, there are loads of logging libraries that support both stdout and file logging. My policy is to support both for my project and it has been almost no burden so far (in Python and in C). Not everything is containers, and having a feature like logging does not mean it cannot be used in a container.
Earlier quoted context omitted.
That's a very weird way to look at it. Static linking was there before everything else. gcc/ld and, well, any other C/C++ toolchain can do that as well. There is a reason this isn't usually done. It's like you are trying to spin a bad thing into something good.
Just because you don't like the single binary that works everywhere, doesn't mean that others find it a problem. One approach doesn't fit every possible situation.
Earlier quoted context omitted.
Just because you don't like the single binary that works everywhere, doesn't mean that others find it a problem. One approach doesn't fit every possible situation.
Even if you think the wasted ram and the security issues isn't a problem, why is that an argument especially for Go, when almost every other language can be built into a single static file as well?
ie other languages may not work, is less tested, and not normally done.
Is possible to for MySQL ?
Postgres (which I would recommend over MySQL any day) seems to have a saner client-initiated protocol. I only read part of the spec, but I'll try to see what pattern would need matching later today.
We 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 multiple…
You can get the SSH client to connect over this either by using an openssl s_client trick, or by just using my little tunnel tool (https://github.com/joushou/tunnel).
Earlier quoted context omitted.
There are a number of work and wifi proxies which won't allow out a lot of traffic, based on port. A multiplexer like this can work around such (assumed) well-intentioned but poorly implemented protections.
Wouldn't a VPN or tunnelling solution be better? You pass all your traffic through a fixed port on one host, then unwrap it and use the web as though the restriction wasn't there.
Earlier quoted context omitted.
Just because you don't like the single binary that works everywhere, doesn't mean that others find it a problem. One approach doesn't fit every possible situation.
Even if you think the wasted ram and the security issues isn't a problem, why is that an argument especially for Go, when almost every other language can be built into a single static file as well?
Go 1.5 has mechanisms for dynamic linking, though.