Home » Posts tagged "node"

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 安全性更新: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,順便看一下大家用什麼...

V8 對 Hash Flooding 的防禦措施

Hash Flooding 問題是指 Hash 這個資料結構是可以被預測 collision 所造成的問題,在隨機的情況下會是 O(1) 的操作,在特定挑選故意讓他 collision 而變成 O(n),當有 n 個元素時,乘起來就會變成 O(n^2)。這算是一種阻斷攻擊 (DoS attack)。

在「About that hash flooding vulnerability in Node.js...」這邊提到了 V8 之前為了避免 Hash Flooding 的問題,關掉了 Startup snapshot 而造成的效能問題,以及後續的很多故事,最後找了長期的解法。

這個解法已經併入 Node.js 裡,預定下個包括的版本是 8.3.0:

The patch to re-enable startup snapshot has been merged into Node.js. It is part of the recent Node.js v8.3.0 release.

不過這表示現有的 LTS (4.8.4 以及 6.11.2) 還是... XD

Telegram 使用 CDN 加速下載

Telegram 說明他們將會使用 CDN 加速:「More Speed and Security!」。

資料在 CDN 的節點上是加密的,金鑰需要透過 Telegram 的 key server 提供:

While these caching nodes are only used to temporarily store public media (imagine Telegram versions of superpopular YouTube hits), all data that goes through them is encrypted with a key unknown to the caching nodes. In other words, we treat these CDN caching nodes just like we treat your internet provider – they only ever get encrypted junk they can't decipher.

但這表示 Telegram 本身有能力解開這些資料?不知道這邊講的是什麼行為...

使用者如果選擇願意公開的話當然沒問題,但這種情況下也不需要 CDN 加密;而當使用者不願意公開時,應該是期望 Telegram 也無法解開這些資料?再來看看到底是怎麼樣的功能要上 CDN?

Archives