start new:
tmux
start new with session name:
tmux new -s myname
Latency Comparison Numbers (~2012) | |
---------------------------------- | |
L1 cache reference 0.5 ns | |
Branch mispredict 5 ns | |
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 us | |
Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
#!/bin/sh | |
# | |
# chkconfig: 2345 55 25 | |
# Description: Nginx init.d script, put in /etc/init.d, chmod +x /etc/init.d/nginx | |
# For Debian, run: update-rc.d -f nginx defaults | |
# For CentOS, run: chkconfig --add nginx | |
# | |
### BEGIN INIT INFO | |
# Provides: nginx | |
# Required-Start: $all |
Data Down / Actions Up
Plain JSBin's
Ember Version Base JSBin's
Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.
This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would
# Tutorial https://www.daimto.com/how-to-get-a-google-access-token-with-curl/ | |
# YouTube video https://youtu.be/hBC_tVJIx5w | |
# Client id from Google Developer console | |
# Client Secret from Google Developer console | |
# Scope this is a space seprated list of the scopes of access you are requesting. | |
# Authorization link. Place this in a browser and copy the code that is returned after you accept the scopes. | |
https://accounts.google.com/o/oauth2/auth?client_id=[Application Client Id]&redirect_uri=http://127.0.0.1&scope=[Scopes]&response_type=code | |
# Exchange Authorization code for an access token and a refresh token. |
Just documenting docs, articles, and discussion related to gRPC and load balancing.
https://github.com/grpc/grpc/blob/master/doc/load-balancing.md
Seems gRPC prefers thin client-side load balancing where a client gets a list of connected clients and a load balancing policy from a "load balancer" and then performs client-side load balancing based on the information. However, this could be useful for traditional load banaling approaches in clound deployments.
https://groups.google.com/forum/#!topic/grpc-io/8s7UHY_Q1po
gRPC "works" in AWS. That is, you can run gRPC services on EC2 nodes and have them connect to other nodes, and everything is fine. If you are using AWS for easy access to hardware then all is fine. What doesn't work is ELB (aka CLB), and ALBs. Neither of these support HTTP/2 (h2c) in a way that gRPC needs.
curl --proxy http://127.0.0.1:<tinyproxy-port> https://httpbin.org/ip
. And I don't use any user authentication for proxy, so I locked down the firewall rules with my laptop IP/32.HTTPS_PROXY=<bastion-external-ip>:<tinyproxy-port> KUBECONFIG=my-kubeconfig kubectl get nodes