61–70 of 75 posts
https://github.com/wikimedia/PyBal
It actually is a bit different in that it advertises VIPs via BGP, so no floating IPs are needed, but you need to be able to configure your upstream routers, and its configuration is much more flexible.
Earlier quoted context omitted.
I have not looked deeply at the implementation, at all, but given that the actual site refers to this as an "algorithm" for LVS, I kinda suspect all the heavy lifting is happening at the kernel level within LVS, and the go code is merely acting as a control program that tells the backend how to behave. Many high performance systems have lower performance scripting languages or similar built in or bolted on, in order…
That's because Erlang's GC is managed on a per-lightweight-process basis, which is possible because of the share-nothing nature of the concurrency model Erlang uses (actor/message-passing). Garbage collection in Go can't be implemented the same way, because Go allows for shared mutable state. That said, the work done to the GC in Go v1.5 seems quite phenomenal, but just because the two runtimes share a piece of termi…
OT: I'm a Go noob and I was wondering if there's something like requirements.txt for Go projects? Or is this usually the way to go? go get -u golang.org/x/crypto/ssh go get -u github.com/dlintw/goconf go get -u github.com/golang/glog go get -u github.com/golang/protobuf/{proto,protoc-gen-go} go get -u github.com/miekg/dns
This looks incredibly brittle. What if one of those dependencies releases a new major version on its master branch that breaks compatibility? It was really surprising to see this done this way. I know go's package management is pretty weak but a serious project like needs reproducible builds. Since all the dependencies are on git they could just use git submodules in a vendor directory or something.
You are not supposed to do this in Go. If you make changes that are API-incompatible, you need to create a new import path. From the Go FAQ:
Packages intended for public use should try to maintain backwards compatibility as they evolve. The Go 1 compatibility guidelines are a good reference here: don't remove exported names, encourage tagged composite literals, and so on. If different functionality is required, add a new name instead of changing an old one. If a complete break is required, create a new package with a new import path.
https://golang.org/doc/faq#get_version
Whether this is a good approach is the question, but pushing API compatibilities to an existing import path is considered to be bad.
(Since creating a new repository for each API-breaking version is annoying, there are sites such as http://gopkg.in/ that allow you to expose version branches as a different import paths.)
How does HN's duplicate link work? I'm asking this because I saw this thread earlier: https://news.ycombinator.com/item?id=10998103 Wouldn't it be fair for that submitter to get karma points?
OT: I'm a Go noob and I was wondering if there's something like requirements.txt for Go projects? Or is this usually the way to go? go get -u golang.org/x/crypto/ssh go get -u github.com/dlintw/goconf go get -u github.com/golang/glog go get -u github.com/golang/protobuf/{proto,protoc-gen-go} go get -u github.com/miekg/dns
Doing "go install github.com/google/seesaw" should do everything for you.
Earlier quoted context omitted.
How is that not "using it in production"? Internal usage is still production usage.
When Google, Facebook, etc. refer to "production" they typically mean google.com, facebook.com, etc. EDIT: If you're going to down-vote this comment, at least provide detaro with the correct answer to his/her question!
Given that it's built on top of LVS, this presumably supports UDP load balancing. If so, that's great, as the available solutions for UDP load balancing are, to my knowledge, quite limited.
https://github.com/google/seesaw/blob/master/common/seesaw/s...
OT: I'm a Go noob and I was wondering if there's something like requirements.txt for Go projects? Or is this usually the way to go? go get -u golang.org/x/crypto/ssh go get -u github.com/dlintw/goconf go get -u github.com/golang/glog go get -u github.com/golang/protobuf/{proto,protoc-gen-go} go get -u github.com/miekg/dns
This is the biggest problem in golang ecosystem. Yes there are many third party solution, but no official one. So different repo use different solution make all solutions invalid.
OT: I'm a Go noob and I was wondering if there's something like requirements.txt for Go projects? Or is this usually the way to go? go get -u golang.org/x/crypto/ssh go get -u github.com/dlintw/goconf go get -u github.com/golang/glog go get -u github.com/golang/protobuf/{proto,protoc-gen-go} go get -u github.com/miekg/dns
This looks incredibly brittle. What if one of those dependencies releases a new major version on its master branch that breaks compatibility? It was really surprising to see this done this way. I know go's package management is pretty weak but a serious project like needs reproducible builds. Since all the dependencies are on git they could just use git submodules in a vendor directory or something.
gopkg.in/mypackage.v3 -> github.com/go-mypackage/mypackage
gopkg.in/bob/mypackage.v3 -> github.com/bob/mypackage
What Go needs is a real package manager that uses the new 1.5 vendor directory to manage dependencies. There have been some attempts (godep, gb), but they aren't very good, especially if you look at how existing languages have solved this (Ruby's Bundler, Rust's Cargo).
[1] https://gopkg.in
Earlier quoted context omitted.
When Google, Facebook, etc. refer to "production" they typically mean google.com, facebook.com, etc. EDIT: If you're going to down-vote this comment, at least provide detaro with the correct answer to his/her question!
I didn't downvote, but your statement in no way refutes parent argument. Typically =/= always. It's similar to someone declaring "HN was down", and you reply by saying "HN is typically up"