Tor 在德國的 Relay 節點比重過高的問題

在「The German Problem with Tor」這邊提到了 Tor 在德國的 Relay 節點比重過高的問題,遠超過第二名的法國:

This is where we come to Germany, which has the highest amount of Tor relay capacity in the World at 167Gbps, in contrast France is in 2nd place with 64.5Gbps of capacity aka more than 100Gbps lower than Germany.

Welcome to Tor Metrics 這邊可以拉資料出來看,在「rs.html#aggregate/cc」這頁可以看到差距,現在德國的 Relay 是第一名,比重約 37.7%,法國則是第二名,但卻只佔了 16.7%。

主要還是頻寬費用的關係吧?畢竟網路上租主機時也可以感覺到,德國的頻寬真的很便宜...

GitHub 推出 Package Registry

GitHub 推出了「GitHub Package Registry」,可以代管自己開發的軟體。

目前支援 npm (Node.js)、DockerMaven (Java)、NuGet (.NET)、RubyGems (Ruby) 五個平台,

隔壁 GitLab 說我們早就有了而氣噗噗中:「Packaging now standard, dependency proxy next?」。

Anyway,省下一些事情,以前會透過 CI/CD 丟到像是 packagecloud.io 這樣的服務上讓內部使用,現在看起來 GitHub 上面可以解決一些簡單的情境...

AWS Lambda 支援 Node.js v8.10

AWS LambdaNode.js 宣佈支援目前最新的 LTS 版本,v8.10:「AWS Lambda Supports Node.js v8.10」。

You can now develop your AWS Lambda functions using Node.js v8.10. In addition to the leveraging new features in Node.js v8.10 such as the new V8 6.0 engine, Lambda functions written in Node.js 8.10 can now use the async/await pattern to specify error or return values for the function execution.

就如同公告裡提到的,有很多語言特性是大家等很久的... 有些老東西可以考慮重寫 :o

Rust 是不錯啦,不過...

作者寫了一篇「Creating Rust-based NodeJS modules」講同樣演算法 Node.js 要跑 3.5 秒,Rust 只要跑 130ms,所以 Rust 很棒棒之類的...

So about 3.5 seconds for an answer, in web time that is like an eternity. Our algorithm is a very straight forward one, basically just a filter on a large array.

The exact same algorithm, with the exact same CSV and coordinates is now executing in about 130ms.

然後仔細看了一下他的範例,holy...

這讓我想到之前在「看到 zmx 貼了之前的連結,更確信 Uber 的問題不是技術問題了...」這篇提到的文章「Unwinding Uber’s Most Efficient Service」:

很想講「傻逼你先把演算法修好再來怪 Node.js 慢」,程式會愈來愈難維護都是你們這種人引入一堆複雜的東西 -_-

ElastiCache 支援 r4.* 了

每年 AWS re:Invent 要到的時候就會有很多新的消息出來,Amazon ElastiCache 的團隊應該也是配合著這一波放出消息:「Amazon ElastiCache Now Supports the R4 Node Family」。

包括了 memcachedRedis 都支援了:

Amazon ElastiCache now supports R4 node types. R4 nodes are optimized for latency sensitive and memory intensive workloads. They come in six sizes, providing 12.3GiB to 407GiB of available in-memory capacity. By setting up a 15-shard cluster for Redis, you can scale up to 6.1TiB of in-memory capacity. For Memcached, you can set up a 20-node cluster to support up to 8.14 TiB in-memory workloads. Equipped with the Intel Broadwell processor, and improved networking, R4 node family offers superior performance over the popular R3 node family.

這兩個應用都是看記憶體吃飯的...

Node.js 第一個 8.x LTS 推出

推出啦:「Node v8.9.0 (LTS)」,另外可以看「NEWS: Node.js 8 Moves into Long-Term Support and Node.js 9 Becomes the New Current Release Line」這篇。

從 6 到 8 多了 async & await (ES7),應該會是對整個生態系改變最大的功能了,可以預期會有一堆人濫用... XD

剛剛測 nlts 參數發現還沒更新,先用 n 8.9.0 換上去...

Node.js 安全性更新:zlib...

前幾天「Node.js 預定在十月 24 號發表安全性更新」提到 Node.js 會發表安全性更新,已經看到 4/6/8 都出新版了:「Node v4.8.5 (Maintenance)」、「Node v6.11.5 (LTS)」、「Node v8.8.0 (Current)」。

這次安全更新的 CVECVE-2017-14919

CVE-2017-14919 - In zlib v1.2.9, a change was made that causes an error to be raised when a raw deflate stream is initialized with windowBits set to 8. On some versions this crashes Node and you cannot recover from it, while on some versions it throws an exception. Node.js will now gracefully set windowBits to 9 replicating the legacy behavior to avoid a DOS vector. nodejs-private/node-private#95

zlib 的 manualwindowBits 說明:

For the current implementation of deflate(), a windowBits value of 8 (a window size of 256 bytes) is not supported. As a result, a request for 8 will result in 9 (a 512-byte window). In that case, providing 8 to inflateInit2() will result in an error when the zlib header with 9 is checked against the initialization of inflate(). The remedy is to not use 8 with deflateInit2() with this initialization, or at least in that case use 9 with inflateInit2().

唔?XD

另外文章可以看出來 Node.js 團隊是選擇在 GitHub 上用另外一個 organization 在管這類不會事前公開的事情...

nvm 換 n

前幾天在 Twitter 上抱怨 nvm 很慢,導致 Zsh 開起來很頓 (然後也同步到 Facebook 上):

原因在於 .bashrc 或是 .zshrc 內初始化 nvm 時會呼叫 npm config get prefix,而這個命令很慢:「`npm config get prefix` takes incredibly long (7 - 70 seconds) #14458」。

後來在 Facebook 的留言處有朋友提了幾個方案... 其中一個是 n,花了些時間看軟體架構,有夠簡單... XD 對於不是拿 Node.js 開發的人應該是夠用了 (我只拿來跑一些用 Node.js 寫的工具)。

整個軟體就一個 shell script,把他丟進 ~/bin/ 裡面 (我有把 ~/bin/ 放到 PATH 裡),就可以用了。透過 N_PREFIX 設定他的基地 (預設是 /usr/local,我是設成 $HOME),剩下就跑 n lts,他就把 nodenpm 兩個檔案裝好給你用。

路徑的部份要自己設定,將 $N_PREFIX/node_modules/.bin 放進 PATH,這樣安裝起來的模組如果有可執行工具可以用才能直接跑 (像是 gulp.js 的命令)。

另外,之所以會說不適合開發者用的部份,是因為 module 是跨版本共用的 (切換 node 版本時就是用另外一個版本配上去 XD),所以比較不適合開發者使用...

推廣使用 Makefile...

在「Time for Makefiles to Make a Comeback」這篇裡面作者努力介紹 Makefile 這個工具...

UpdateCQD 把全文翻譯出來了:「該把 makefile 請回來了」。

看得出來作者對於 Node.js 體系一直在發明這樣的工具有種厭煩感... 從 GruntGulpWebpack、...

我自己也還是覺得 Makefile 很好用... (當然也或多或少跟 FreeBSDPorts 使用 Makefile 當作底層有關)

Makefile 的想法就是解決相依性的問題:當這個檔案更新了,那麼有哪些檔案需要更新。而這其實跟目前很多工具想做的事情一樣...

另外 Makefile 是 Tuning-complete,如硬要放複雜的邏輯也沒問題,不過大家一般還是習慣拿許多 Unix command 協助,不需要什麼都自己來 (類似於 Unix philosophy)。

Homebrew 蒐集到的安裝資訊

在「Homebrew Analytics Install On Request Events — Homebrew」這邊,Homebrew 利用了傳回來的資訊算出 2016/07/14 到 2017/07/14 的安裝套件次數,列出前一千名。(我是把他關掉,因為隱私問題不想要傳出去... 參考「Homebrew 會將安裝資訊送到 Google Analytics 上」這篇。)

比較有趣的是第一名的 node 超級多,比第二名加第三名的 git + wget 還多...

拿來翻一翻還 ok,順便看一下大家用什麼...