從 IndieHackers.com 上掃出各種「成功的方法」

Indie Hackes 是個放各種「成功案例」的網站:

Indie Hackers is a place where the founders of profitable businesses and side projects can share their stories transparently, and where entrepreneurs can come to read and learn from those examples. It's also a community where individual "indie hackers" can come together to share their experiences, give and receive feedback, and rely on one another for support.

而文章的作者把上面的文章拿出來分析,得到了一些有趣的資訊:「Reverse Engineering A Successful Lifestyle Business: Here’s Everything I’ve Learned From Reading IndieHackers.com」。


The 4-Hour Workweek by Tim Ferriss (5x)
The Hard Thing About Hard Things by Ben Horowitz (5x)
Zero to One by Peter Thiel (4x)
The Lean Startup by Eric Ries (4x)
Four Steps to the Epiphany by Steve Blank (3x)
Steve Jobs by Walter Isaacson (2x)
High Output Management by Andy Groove of Intel (2x)
Good to Great by Jim Collins (2x)
Traction by Gabriel Weinberg and Justin Mares (2x)
Built to Sell by John Warrillow (2x)
The Personal MBA by Josh Kaufman (2x)
Start Small, Stay Small by Rob Walling (2x)
The Power Of The Subconscious Mind by Joseph Murphy (2x)

然後是各種技巧 (?):

On Raising Prices (19x)
This was the most common advice. The easiest way to increase revenue: raise your prices! Don’t be scared to ask for money.

Real Artists Ship (9x)
Our first idea is a grand opening, a big launch, a press release, or major media coverage. We default to thinking we need an advertising budget. Our delusion is that we should be Transformers and not The Blair Witch Project. – Ryan Holiday

KISS (9x)
Automation (8x)
Start Charging Straight Away (8x)


Web Cache Deception Attack

在「How (Not) to Control Your CDN」這邊看到了「Web Cache Deception Attack」這個攻擊方式。

攻擊的手法是利用網站會把 /user/personal-info/foo.css/user/personal-info 視為一樣的內容時,配合 CDN 或是 reverse proxy server 會把 .css 設定無差異 cache 時,就可以在 cache server (cache edge) 取得使用者的敏感資料。

這主要是 url routing 的條件放太寬造成的。

另外 Mark Nottingham 還建議 cache 應該在 origin server 上控制,而非在 CDN 上設定。也就是說,在 origin server 上送出 Cache-Control,讓 CDN 或是 reverse proxy server 使用這個值來判斷 cache。

hashcat v3.00

hashcat 是個用暴力法拿來計算各種 reverse hash 的的工具,也就是對於 HASH(key) = value 時,給 value 的值,要求得出 key 的值 (被稱為 Preimage attack)。

雖然是暴力法,但還是花了很多力氣加速,尤其在這個 GPU 已經很常見的年代,這套軟體也支援透過 GPU 加速運算。

先前的版本是 CPU 與 GPU 分開兩個版本可以用 (CPU 版本的叫 hashcat,GPU 版本的叫做 oclHashcat),而 GPU 的版本只支援 nVidiaAMD 兩家大廠的顯卡。

而在 v3.00 版,透過 OpenCL 的界面將這些全部都合而為一了:「hashcat v3.00」,所以不只是支援 CPU 與 nVidia + AMD 的 GPU,還包括了:

  • GPU
  • CPU
  • APU
  • DSP
  • FPGA
  • Coprocessor
  • Anything else which comes with an OpenCL runtime

也特別提到,Intel CPU 上內建的 GPU 部份也可以拿來用了:

For example, Intel CPUs will now instantly pop up as an available OpenCL device after you've installed the Intel OpenCL runtime.

也因為透過 OpenCL,如果有多種不同類型的加速方式,新版 hashcat 也可以同時使用。

另外這次效能評估 (與舊版比較) 也做出來了:「hashcat 2.01 / 3.00 performance comparison」,可以看到比較新一點的卡整體都有進步,而舊的卡有可能是對 OpenCL 的最佳化或是 overhead 比較敏感,慢了不少...

解譯機械碼的 Panopticon

Panopticon 看起來頗不錯,可以直接解機械碼轉成 assembly,再把 flow 畫出來讓人理解:

不過還不知道遇到 dynamic self-decoding 的程式會怎麼處理,另外我記得好像有些商用的 solution 已經有提供了,不知道相比起來如何。

用 curl 測試 Reserve Proxy 是否正確運作

架好 reverse proxy 後要測試可以用 curl--resolve 的功能來確認。

curl -v --resolve i.kfs.io:443: https://i.kfs.io/article5/global/364,324,6v1/original.png > /dev/null

其中 --resolve 的第三個參數一定要用 IP address,你可以看到他的運作原理:

* Added i.kfs.io:443: to DNS cache

HAProxy 1.6 的兩個大功能:Quote 以及 Lua

HAProxy 1.6.0 出版的公告文章:「[ANNOUNCE] HAProxy 1.6.0 released」。

兩個大功能,第一個是「It’s 2015, let’s use QUOTE in configuration file」,可以用引號了... 另外一個是「Lua Scripting」,需要 Lua 5.3+。

還有提到一些改進,像是支援 SNI,以及對 HTTP/2 的計畫。

Varnish 的 Super Fast Purger...

Reverse Proxy 的 Cache Infrastructure 在遇到 cache invalidate 都是很討厭的問題,不是不能做,而是效能不太好... 常見的作法是設計成不用 purge 的形式,只要是需要更新,就產生不同的 url,而舊的 url 在沒人 access 後會透過各種 Cache algorithms 自動回收掉,像是 LRU (Least Recently Used) 之類的演算法。

發展久了之後也因此衍伸出很多不同的架構,像是 groupcache 就是假設在同一個 address 的內容永遠不會變的前提。

Varnish Cache 這次發表的東西則是打算從根本問題解決,也就是想辦法讓 purge (cache invalidate) 的成本降低:「Simple scales better and faster in the real world」、「VAC 2.0.3 with high performance cache invalidation API (aka the Super Fast Purger)」。

官方的說法,在大台機器上可以到 60k reqs/sec:

Kristian nonchalantly mentioned that the Super Fast Purger did 60,000 requests per second, on a 6 core Xeon with 36GB memory, traffic over a gigabit network to a single Varnish Cache server, with httperf as test client. But we believe the Super Fast Purger can do a lot more with a little love and tuning.

Squid 效能不好,ATS 的文件很傷,是該找時間來測試看看...