Original: http://www.shadowandy.net/2012/03/asus-rt-n66u-tomatousb-firmware-flashing-guide.htm
/* | |
* This program is free software: you can redistribute it and/or modify | |
* it under the terms of the GNU General Public License as published by | |
* the Free Software Foundation, either version 3 of the License, or | |
* (at your option) any later version. | |
*/ | |
#include <arpa/inet.h> | |
#include <linux/if_packet.h> | |
#include <stdio.h> |
#define _XOPEN_SOURCE 700 | |
#include <signal.h> | |
#include <unistd.h> | |
int main() | |
{ | |
sigset_t set; | |
int status; | |
if (getpid() != 1) return 1; |
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:
- Go HTTP standalone (as the control group)
- Nginx proxy to Go HTTP
- Nginx fastcgi to Go TCP FastCGI
- Nginx fastcgi to Go Unix Socket FastCGI
#!/usr/bin/python3 | |
# By Steve Hanov, 2011. Released to the public domain. | |
# Please see http://stevehanov.ca/blog/index.php?id=115 for the accompanying article. | |
# | |
# Based on Daciuk, Jan, et al. "Incremental construction of minimal acyclic finite-state automata." | |
# Computational linguistics 26.1 (2000): 3-16. | |
# | |
# Updated 2014 to use DAWG as a mapping; see | |
# Kowaltowski, T.; CL. Lucchesi (1993), "Applications of finite automata representing large vocabularies", | |
# Software-Practice and Experience 1993 |
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} | |
module Main where | |
import Test.QuickCheck | |
class Arbiter f r where | |
arbiter :: f -> Gen r | |
instance Arbiter r r where |
Rich Hickey • 3 years ago
Sorry, I have to disagree with the entire premise here.
A wide variety of experiences might lead to well-roundedness, but not to greatness, nor even goodness. By constantly switching from one thing to another you are always reaching above your comfort zone, yes, but doing so by resetting your skill and knowledge level to zero.
Mastery comes from a combination of at least several of the following:
(A book that I might eventually write!)
Gary Bernhardt
I imagine each of these chapters being about 2,000 words, making the whole book about the size of a small novel. For comparison, articles in large papers like the New York Times average about 1,200 words. Each topic gets whatever level of detail I can fit into that space. For simple topics, that's a lot of space: I can probably walk through a very basic, but working, implementation of the IP protocol.
This exemplary initial setup uses two devices /dev/sdb
and /dev/sdc
but can be applied to any amount of devices by following the steps with additional devices.
Create keyfile:
dd bs=64 count=1 if=/dev/urandom of=/etc/cryptkey iflag=fullblock
chmod 600 /etc/cryptkey