The scenario:
- DNS zone
myzone.com
defined in BIND. - Authoritative name server at
123.16.123.1
. - Subzone
sub.myzone.com
with an authoritative name server at123.16.123.10
. - Wishing to forward sub-zone to authoritative name server.
There are three easy to make mistakes in go. I present them here in the way they are often found in the wild, not in the way that is easiest to understand.
All three of these mistakes have been made in Kubernetes code, getting past code review at least once each that I know of.
What do these lines do? Make predictions and then scroll down.
func print(pi *int) { fmt.Println(*pi) }
How to install Ubuntu 14.04.1 LTS 64-bit on a MacBook Pro Retina 15" Mid 2014 (11,3)
... or Why Pipelining Is Not That Easy
Golang Concurrency Patterns for brave and smart.
By @kachayev
This is a guide on how to email securely.
There are many guides on how to install and use PGP to encrypt email. This is not one of them. This is a guide on secure communication using email with PGP encryption. If you are not familiar with PGP, please read another guide first. If you are comfortable using PGP to encrypt and decrypt emails, this guide will raise your security to the next level.
#!/usr/bin/env bash | |
# names of latest versions of each package | |
export NGINX_VERSION=1.15.5 | |
export VERSION_NGINX=nginx-$NGINX_VERSION | |
export VERSION_LIBRESSL=libressl-2.8.1 | |
export VERSION_PCRE=pcre-8.42 | |
#export NPS_VERSION=1.9.32.10 | |
#export VERSION_PAGESPEED=v${NPS_VERSION}-beta | |
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns on recent CPU
L2 cache reference ........................... 7 ns 14x L1 cache
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns 20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs 4X memory
10.3 (Panther): http://swscan.apple.com/scanningpoints/scanningpointX.xml | |
10.4 (Tiger): http://swscan.apple.com/content/catalogs/index-1.sucatalog | |
10.5 (Leopard): http://swscan.apple.com/content/catalogs/others/index-leopard.merged-1.sucatalog | |
10.6 (Snow Leopard): http://swscan.apple.com/content/catalogs/others/index-leopard-snowleopard.merged-1.sucatalog | |
10.7 (Lion): http://swscan.apple.com/content/catalogs/others/index-lion-snowleopard-leopard.merged-1.sucatalog | |
10.8 (Mountain Lion): http://swscan.apple.com/content/catalogs/others/index-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog | |
10.9 (Mavericks): http://swscan.apple.com/content/catalogs/others/index-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog | |
10.9 (Mavericks incl. seeds): http://swscan.apple.com/content/catalogs/others/index-10.9seed-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog |
There are a lot of ways to serve a Go HTTP application. The best choices depend on each use case. Currently nginx looks to be the standard web server for every new project even though there are other great web servers as well. However, how much is the overhead of serving a Go application behind an nginx server? Do we need some nginx features (vhosts, load balancing, cache, etc) or can you serve directly from Go? If you need nginx, what is the fastest connection mechanism? This are the kind of questions I'm intended to answer here. The purpose of this benchmark is not to tell that Go is faster or slower than nginx. That would be stupid.
So, these are the different settings we are going to compare:
// Just before switching jobs: | |
// Add one of these. | |
// Preferably into the same commit where you do a large merge. | |
// | |
// This started as a tweet with a joke of "C++ pro-tip: #define private public", | |
// and then it quickly escalated into more and more evil suggestions. | |
// I've tried to capture interesting suggestions here. | |
// | |
// Contributors: @r2d2rigo, @joeldevahl, @msinilo, @_Humus_, | |
// @YuriyODonnell, @rygorous, @cmuratori, @mike_acton, @grumpygiant, |