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

81–90 of 130 posts

Re: GoBGP: BGP Implemented in Go

#81

Post by mikecb »

zzzcpan wrote: post #65
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…

Go is missing a few things for this. There is no good predictable event-driven polling library for networking with proper error handling and no GC pressure (no heap allocations), etc. And it has to implement its own syscall wrappers, because Go's syscall wrappers on non-blocking FDs call into the scheduler and even produce garbage on some errors. TLS library needs to be predictable too, produce no garbage and play we…

Some think it's very appropriate for high performance networking: https://github.com/google/stenographer

Granted, that uses pfring pretty substantially, but still...

Re: GoBGP: BGP Implemented in Go

#82

Post by pests »

tptacek wrote: post #78
dsr_ wrote: post #40

Earlier quoted context omitted.

The viewpoint you were espousing was, if I understand correctly: I should replace all my existing services with Go/Rust equivalents, unless they handle packets directly. My objection is that you are advocating this in the same narrow-focused way that people advocate node with npm, python with pip, ruby with gem: little or no cooperation with the whole system is available yet. This is perfectly fine from the point of…

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.…

What is the cool trick to implementing BER?

Re: GoBGP: BGP Implemented in Go

#83

Post by educar »

102030485868 wrote: post #50
educar wrote: post #15

I look forward to the first programmer friendly SMTP/IMAP implementation. Haraka is the closest friendly SMTP server I have come across.

I can understand why there hasn't been much movement in the SMTP world. SMTP is pretty hard to get right, as is maybe hinted at by the many RFCs. You really don't want to be making any mistakes because it's a somewhat unforgiving protocol... unless you send an error code.

Agreed. But like most things opensource, it just becomes better over time if someone did a good start :-) .

Re: GoBGP: BGP Implemented in Go

#84

Post by zzzcpan »

tptacek wrote: post #74
zzzcpan wrote: post #65

Earlier quoted context omitted.

Go is missing a few things for this. There is no good predictable event-driven polling library for networking with proper error handling and no GC pressure (no heap allocations), etc. And it has to implement its own syscall wrappers, because Go's syscall wrappers on non-blocking FDs call into the scheduler and even produce garbage on some errors. TLS library needs to be predictable too, produce no garbage and play we…

There's no good predictable event-driven polling library for networking because the whole runtime is a good predictable event-driven polling library for networking. You're not supposed to "event" Go I/O. Virtually every Go program that anyone has deployed at scale has scaled I/O with goroutines (though not necessarily with "concurrent memory access"). With the exception of NTP, I can't see a single example of a servi…

You are not doing event-driven programming just to scale I/O, you are doing it to avoid mutexes and concurrent memory access, to have easy cancellation, easy management of connections and other resources, etc.

Re: GoBGP: BGP Implemented in Go

#85

Post by jsmthrowaway »

tptacek wrote: post #78
dsr_ wrote: post #40

Earlier quoted context omitted.

The viewpoint you were espousing was, if I understand correctly: I should replace all my existing services with Go/Rust equivalents, unless they handle packets directly. My objection is that you are advocating this in the same narrow-focused way that people advocate node with npm, python with pip, ruby with gem: little or no cooperation with the whole system is available yet. This is perfectly fine from the point of…

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.…

I would think implementing SNMP from scratch is the reward in itself, right? Are ulcers not a badge of honor for you like they are me?

And yes, I agree. I think we're to the point now where sysadmin-style "I'll wait for Debian to entmoot on this TLS vulnerability and eventually drop something" server maintenance is on its way out for those who operate cattle. Especially high-visibility cattle, as you imply. The industry is teasing the post-distro world into existence but doesn't yet know what it's dealing with on that point. I don't even consider CoreOS a distribution, for example; I think it's more of what Linux will look like in several years time for cattle herders, while Debian and friends will continue to go in pretty hard on pets.

Dynamic linking creates more problems than solutions in a cattle fleet as opposed to a pet fleet. People who philosophically argue for one or the other are expressing their preference for how to administer a server and do not realize that it is a preference, and not "correctness," per se. The package manager argument is the same way. Execute the code and get it done, or be "correct" and only apply updates through RPM. Cattle, pets. It's all cattle and pets, and the arguments that spawn between the cattle camp and the pet camp will never be resolved, this thread included. People need to realize this, that there is not one way to operate a server, and my way is not more correct than your way.

My way, for example, comes with the baggage of an expected organizational structure to enable its mission. That's not always easy, and I understand that. I can say, however, that the SRE/cattle way makes a hell of a lot of sense at scale.

Re: GoBGP: BGP Implemented in Go

#86

Post by arca_vorago »

nickpsecurity wrote: post #56
npizzolato wrote: post #42

Earlier quoted context omitted.

I don't think it's a lot to ask for a readme to contain the full name of the acronym it's implementing and maybe a link to a wikipedia page. I mean, it already has a link to the golang website, but no mention of what BGP actually is.

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 a barrier is not a good thing for encouraging education.

After all, there is a reason it's called the wikipedia rabbit hole, do you know how often I start with a quick search and suddenly it's an hour later and I've learned all about $something-other-than-originally-intended?

Re: GoBGP: BGP Implemented in Go

#87

Post by steveklabnik »

bogomipz wrote: post #73
baq wrote: post #58

Earlier quoted context omitted.

i don't know if it counts, but there's musl-gcc, right?

curious, is there no glibc solution? Its just the libnss* that requires dynamic linking?

https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked...

Re: GoBGP: BGP Implemented in Go

#88

Post by xorcist »

tptacek wrote: post #78
dsr_ wrote: post #40

Earlier quoted context omitted.

The viewpoint you were espousing was, if I understand correctly: I should replace all my existing services with Go/Rust equivalents, unless they handle packets directly. My objection is that you are advocating this in the same narrow-focused way that people advocate node with npm, python with pip, ruby with gem: little or no cooperation with the whole system is available yet. This is perfectly fine from the point of…

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,

That's a misunderstanding. What Debian, and every other mature Linux distribution, gives you are the tools to not only rebuild a package on a moments notice (try to build any non trivial third party package sometime, and compare that to rebuilding the Debian package) but also keep track of those patches over time (where did it originate? bug id? upstreamed yet?) and keep a bird's eye view over deployment (which nodes? when?). You need to ask yourself those questions, because your auditor will.

Good for you to implement SNMP, and using the f word in writing, but maintaining infrastructure is something else. Your reason to not use Debian for critical infrastructure should be because of contractual liabilities and/or support reasons, its build tools and associated policies are solid. It's not the only way to roll, but it's a perfectly valid one.

Re: GoBGP: BGP Implemented in Go

#90

Post by _wmd »

tptacek wrote: post #78
dsr_ wrote: post #40

Earlier quoted context omitted.

The viewpoint you were espousing was, if I understand correctly: I should replace all my existing services with Go/Rust equivalents, unless they handle packets directly. My objection is that you are advocating this in the same narrow-focused way that people advocate node with npm, python with pip, ruby with gem: little or no cooperation with the whole system is available yet. This is perfectly fine from the point of…

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 back to Debian-patched versions as part of the normal upgrade process assuming you versioned your custom packages carefully.

A well run Debian shop is a thing to be seen, unfortunately it's not cohesively documented in any one location on the Internet. If there's any problem encountered in the wild on the Internet, after 22 years, there is almost certainly a solid process built into Debian to handle it.

Compare that to home directories full of tarballs of binaries with dubious compiler settings and godknows what else, I have no idea why someone would advocate against it, assuming of course they've actually done sysadmin anywhere aside from the comfort of an armchair

Post reply on HN