Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GoBGP: BGP Implemented in Go

github.com

Post reply on HN
Print view View original

91–100 of 130 posts

Re: GoBGP: BGP Implemented in Go

#91

Post by tptacek »

_wmd wrote: post #90
tptacek wrote: post #78

Earlier quoted context omitted.

If the Debian people don't want to include Go for some logistical or religious or religiously logistical reason, that's fine with me. I don't think people should run critical infrastructure from Debian releases --- when things go wrong, you want to be prepared to patch source on a moment's notice, rather than waiting for the upstream synchronization dance --- but hardly anyone seems to agree with me on that, either.…

> when things go wrong, you want to be prepared to patch source on a moment's notice, rather than waiting for the upstream synchronization dance This is IMHO the most backwards logic ever. Everything about dpkg and apt makes this process easy, from running an internal custom packages repository, through to "apt-get source" for any system package on a moment's notice, through to having everything just magically revert…

It's super easy to install a patch using dkpg and apt. I didn't question that.

The problem is that you have to wait for the patch to be bundled. I've watched that take a long time, while services I knew to be vulnerable had to sit there and be vulnerable because the organization deploying the service didn't have any infrastructure to apply a custom patch.

Consider the degenerate case, where you have to wait for a Debian patch because you paid for the research that found the vulnerability. More than one of my clients wound up in that situation. But that's not the only way to learn about a simple, critical source patch that won't land in a Debian patch for days.

Re: GoBGP: BGP Implemented in Go

#92

Post by pcwalton »

15155 wrote: post #34
tptacek wrote: post #11

This is the sort of thing Go really shines on: network and infrastructure services that would ordinarily be provided by big ugly C programs, where the latency requirements are significant but not as bad as raw packet forwarding. If your current best alternative is a C program, I'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

RE: the (or Rust) comment- All of these services would be better suited for a language which has blessed async IO, concurrency, parallelism primitives. Go has these, Rust does not. pthreads are not the answer. I much prefer Rust, but Go's stdlib and concurrency features far exceed that of Rust at the moment.

> All of these services would be better suited for a language which has blessed async IO, concurrency, parallelism primitives. Go has these, Rust does not. pthreads are not the answer.

Go does not have truly async I/O. It has a userspace (M:N) implementation of threaded, synchronous I/O. There is a distinction, and it's not an academic one.

Rust uses the kernel-level (1:1) implementation of threaded, synchronous I/O, with async I/O provided by mio if you want it.

There is no meaningful distinction between Go's language-level primitive channels and Rust's MPSC channels in the standard library. Not supporting generics is a good reason to put channels directly in the language, but that doesn't apply to Rust.

Additionally, I don't see how Go provides any parallelism primitives that Rust doesn't. In fact, Rust's parallelism (particularly data parallelism) libraries far exceed the capabilities of Go's, mostly because of SIMD and generics which allow you to build highly optimized data parallel abstractions. If I tried to parallelize the project I work on in Rust using Go's built-in primitives, it would be far slower than sequential.

Re: GoBGP: BGP Implemented in Go

#93

Post by _wmd »

tptacek wrote: post #91
_wmd wrote: post #90

Earlier quoted context omitted.

> when things go wrong, you want to be prepared to patch source on a moment's notice, rather than waiting for the upstream synchronization dance This is IMHO the most backwards logic ever. Everything about dpkg and apt makes this process easy, from running an internal custom packages repository, through to "apt-get source" for any system package on a moment's notice, through to having everything just magically revert…

It's super easy to install a patch using dkpg and apt. I didn't question that. The problem is that you have to wait for the patch to be bundled. I've watched that take a long time, while services I knew to be vulnerable had to sit there and be vulnerable because the organization deploying the service didn't have any infrastructure to apply a custom patch. Consider the degenerate case, where you have to wait for a Deb…

You bundle or create it yourself..

    $ apt-get source bash
    $ cd bash*/
    $ quilt new my_urgent_patch
    $ patch -p1

Re: GoBGP: BGP Implemented in Go

#94

Post by pcwalton »

wolf550e wrote: post #64
steveklabnik wrote: post #55

Earlier quoted context omitted.

The Rust approach is, Rust's safety guarantees work for concurrency, but the details of that concurrency are left up to libraries, not the language. Since the safety is in the language, things are always safe, but you get the flexibility to do what you need. You have to remember, Rust is a systems language. Which means that you need access to what the system gives you, and that means at least OS threads and both sync…

That's excellent and must be this way to allow programming microcontrollers or linux kernel modules in Rust, but you guys also need a blessed cross platform N:M threading async I/O sockets and files library, so people can write snmp/mail/web/etc servers/proxies/etc in Rust.

Few C implementations of these applications use M:N threading. M:N threading was tried early on in Linux's history and was abandoned for a reason. It is not a requirement for implementing those applications; in fact, it'll always be suboptimal from a performance point of view, especially in low-level languages like Rust. (Note that I'm not saying it's not fast enough for most applications, or that it was the wrong choice for Go, just that it's not optimal.)

I think the right solution is something like async/await to make truly asynchronous programming palatable. But in the meantime, 1:1 threading is really not that bad on Linux, because the kernel is very optimized.

Re: GoBGP: BGP Implemented in Go

#95

Post by pcwalton »

15155 wrote: post #49
steveklabnik wrote: post #43

Earlier quoted context omitted.

In general, almost every stdlib will be "better" than Rust's, as we're taking an "anti-batteries included" approach. And while Go does have great built-in stuff for a certain kind of concurrency, Rust's approach is more flexible and safer. It's a tradeoff, not a "far exceed" in my mind.

Isn't the Rust approach the Ruby, Python, or C++ approach?: give pthreads, rely on the community to produce a fragmented, incompatible ecosystem.

That hasn't been the case. In practice, mio is the standard for everything asynchronous in Rust.

Adopting Go's approach would force either asynchronous I/O or M:N threading on everyone, which is unacceptable for Rust's goals.

Re: GoBGP: BGP Implemented in Go

#96

Post by nickpsecurity »

arca_vorago wrote: post #86
nickpsecurity wrote: post #56

Earlier quoted context omitted.

A quick Google solves that problem. Anyone that wouldn't do that much is unlikely to be valuable to the project. It's a nice filter at the least.

Bah accidentally downvoted you nick, sorry. Since I downvoted though, I might as well play the game as if I had a reason (because it annoys me when people dv without a reason): I think the request for some basic information without forcing the reader to google/duckduckgo/wikipedia some of the most basic info (such as full name, basic description) is not too much to ask from a journalistic perspective and using it as…

If i do it, I just load up comments of that person and upvote any decent comment tgey have. Cancels it out.

On other issue, here's what typing BGP into Google gace me at the top: "Border Gateway Protocol (BGP) is a standardized exterior gateway protocol designed to exchange routing and reachability information among autonomous systems (AS) on the Internet. The protocol is often classified as a path vector protocol but is sometimes also classed as a distance-vector routing protocol."

Some things are hard to search for. Others, like BGP protocol, are so common you'll get it easily. Those can default on Google. Further, what use is a programmer going to be in robustly implementing the protocol if they can't figure that out? Hence the filter part. So, my position is more solid now that I Googled it.

Re: GoBGP: BGP Implemented in Go

#97

Post by xorcist »

poooogles wrote: post #60
xorcist wrote: post #28

Earlier quoted context omitted.

Not really. Neither the BGP layer nor the packet forwarding layer in that big Cisco box of yours is moving away from C code. Standard network software such as Postfix and OpenSSH took ten years to replace their predecessors, and their eventual replacement will be just as gradual. It's not happening right now, so I think it's a bit of a stretch to call it a trend.

I thought the replacement of Telnet with OpenSSH was fairly fast? Few years at most, it seemed to almost happen over night compared to the move from SSL to TLS for example.

SSH had been around for some five years or so before OpenSSH arrived. It slowly gained popularity on telnet/SSL and kerberized telnet because of the trivial small scale deployment, but also because it was a drop in replacement for rsh. Had it been fundamentally different it wouldn't have gone so easy, and I suspect the familiar language helped there.

Re: GoBGP: BGP Implemented in Go

#98

Post by tptacek »

_wmd wrote: post #93
tptacek wrote: post #91

Earlier quoted context omitted.

It's super easy to install a patch using dkpg and apt. I didn't question that. The problem is that you have to wait for the patch to be bundled. I've watched that take a long time, while services I knew to be vulnerable had to sit there and be vulnerable because the organization deploying the service didn't have any infrastructure to apply a custom patch. Consider the degenerate case, where you have to wait for a Deb…

You bundle or create it yourself.. $ apt-get source bash $ cd bash*/ $ quilt new my_urgent_patch $ patch -p1

That's fine. I don't care what you do with your self-built binaries once you manage to build them yourself. But too many firms have no infrastructure in place to do that. They wait for upstreams to synchronize to fix security flaws that they could fix directly.

Re: GoBGP: BGP Implemented in Go

#99

Post by mc808 »

stingraycharles wrote: post #3
dragonshed wrote: post #2

I assume BGP == Border Gateway Protocol https://en.wikipedia.org/wiki/Border_Gateway_Protocol Suggestion: include a quick abstract what what BGP is with a link for more information.

I don't think this is necessary. If this is relevant to you, you will know exactly what it is, in the same way that GoDNS would be obvious to people who know what DNS is.

You can't get very far in life if you assume every acronym you encounter is irrelevant to you if you don't already know what it stands for.

Re: GoBGP: BGP Implemented in Go

#100

Post by rmdoss »

I remember years ago when every new PHP application would have "PHP" before its name. PHPNuke, PHPMyadmin, etc, etc.

Seeing the same trend with Go now. Why add the language name to the software name? Real question...

Post reply on HN