Rule 11 definitely applies to most new technology that’s being hyped (and overhyped) in the networking world. But while some things stay the same, others actually do change. From one of my readers—
Much of the current “trends” in networking are largely just new marketing-speak on old concepts, but some (I’ll propose) are actually new, or require new ways of thinking—which is which, or for a simpler version: how (really) should I change my thinking to reflect the new-networking-order?
This question rebounds through the networking industry today—how, really, do I need to change my thinking to cope with the new networking order? There are, on the face of it, three options available. Let me begin with a story from a prior career to set the stage.
A long time ago, in a galaxy far away, I worked on airfield electronics and communication systems. Things like RADAR systems, wind speed measurement systems, TACANs, VORs, crypto hardware, MUX’s, inverse MUX’s, and even telephone switches. There was a point when I saw something interesting happening where I lived and spent my time. The TACAN and VOR, for instance, were replaced by new gear. Instead of half splitting, measuring things, and replacing individual components, Continue reading

The post Worth Reading: Gone in six characters appeared first on 'net work.

The post Worth Reading: Gone in six characters appeared first on 'net work.
On today's episode of Datanauts we learn about Snap, an open source telemetry framework to make collecting, processing, and publishing data center metrics modular, dynamic, and open. Snap was originally developed by Intel.
The post Datanauts 033: Making Telemetry A Snap With Intel’s Open Framework appeared first on Packet Pushers.
On today's episode of Datanauts we learn about Snap, an open source telemetry framework to make collecting, processing, and publishing data center metrics modular, dynamic, and open. Snap was originally developed by Intel.
The post Datanauts 033: Making Telemetry A Snap With Intel’s Open Framework appeared first on Packet Pushers.
Go native vendoring (a.k.a. GO15VENDOREXPERIMENT) allows you to freeze dependencies by putting them in a vendor folder in your project. The compiler will then look there before searching the GOPATH.
The only annoyance compared to using a per-project GOPATH, which is what we used to do, is that you might forget to vendor a package that you have in your GOPATH. The program will build for you, but it won't for anyone else. Back to the WFM times!
I decided I wanted something, a tool, to check that all my (non-stdlib) dependencies were vendored.
At first I thought of using go list, which Dave Cheney appropriately called a swiss army knife, but while it can show the entire recursive dependency tree (format .Deps), there's no way to know from the templating engine if a dependency is in the standard library.
We could just pass each output back into go list to check for .Standard, but I thought this would be a good occasion to build a very simple static analysis tool. Go's simplicity and libraries make it a very easy task, as you will see.
We use golang.org/x/tools/go/loader to Continue reading