難得看到 John Resig 的 Blog 更新,在講 Mastodon

jQuery 的發明人 John Resig 已經超久沒更新 blog 了,雖然有訂起來但沒想到會看到他更新:「Twitter vs. Mastodon」。上次的更新是 2016 年初,快七年了。

基本上裡面就是解釋 TwitterMastodon 的差異,然後順便介紹他自己的 Mastodon 帳號。

不過目前看了一輪,ActivityPub 的各種實做還是離理想差了一截,可能會先繼續龜著...

Mozilla 推出在本地端直接翻譯的 Firefox Translations

Mozilla 推出了「Firefox Translations」這個 Firefox 上的套件。

主打的就是 offline 這件事情,保有隱私性:

Firefox Translations provides automated translation of web content. Unlike cloud-based alternatives, translation is done locally, on the client-side, so that the text being translated does not leave your machine.

Hacker News 上的討論「Firefox Translations: Translate websites in your browser without using the cloud (addons.mozilla.org)」可以看到有些人有提到效果,雖然沒有像雲端服務的準確,但算是可用:

I've just installed it, and I'm impressed so far. I've only run it against some sample German Wikipedia articles (https://de.wikipedia.org/wiki/Clan_of_Xymox), but it produces surprisingly readable text. I also particularly like the "highlight potential errors" option to flag stuff that even the translation service thinks might be a bit off.

It's not nearly as speedy as Google Translate, but I'll take that happily if it means keeping it local.

從頁面上列出的支援語言可以看出還是以歐美用到的語系為主,然後下方也有說明這個專案是包括其他計畫的贊助累積出來的:

Firefox Translations was developed with The Bergamot Project Consortium, coordinated by the University of Edinburgh with partners Charles University in Prague, the University of Sheffield, University of Tartu, and Mozilla. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 825303.

不過比較好奇的是在頁面上有提到 CPU 需要 SSE4.1 能力... 這樣就有兩個問題了,第一個是 browser extension 可以直接跑 SSE4.1 指令集?另外一個疑問就是,AppleARM 架構就無法支援嗎 (應該也有類似的加速指令集),現在是 x86 限定?

A CPU that supports SSE4.1 extensions is required for this addon to function properly. If it doesn't, an error will be displayed when the translation is being started.

就算現在限制很多,看起來還是個很有前途的計畫,也許有機會移植到其他瀏覽器上?

AWS 推出加速 Lambda 啟動速度的 Lambda SnapStart

今年 AWSre:Invent 又開始了,這一個禮拜會冒出蠻多新功能的,挑自己覺得比較有興趣得來寫。

AWS 針對 Lambda 推出 Lambda SnapStart,改善冷啟動的速度:「New – Accelerate Your Lambda Functions with Lambda SnapStart」。

他拿了一個比較明顯的例子,JavaSpring Boot,範例在「Serverless Spring Boot 2 example」這邊,冷啟動的速度可以從 6 秒降到 200ms:

SnapStart has reduced the cold start duration from over 6 seconds to less than 200 ms.

方法就是把 initialization 的程式完成後的記憶體打一份 snapshot 存起來,之後的冷啟動第一動變成是 restore 而非再 initialize:

With SnapStart, the initialization phase (represented by the Init duration that I showed you earlier) happens when I publish a new version of the function. When I invoke a function that has SnapStart enabled, Lambda restores the snapshot (represented by the Restore duration) before invoking the function handler. As a result, the total cold invoke with SnapStart is now Restore duration + Duration.

不過不是所有的應用程式都可以直接套用,有些要注意的地方,比較好理解的是連線 (像是對後端資料庫的預連線) 以及暫存檔的部份 (像是預先算好某些資料後寫到暫存檔) 都需要重新建立。

比較特別的是亂數產生器需要重新 initialize,不然會有機率產生出一樣的 random data,這個是一般開發者會忽略掉的:

When using SnapStart, any unique content that used to be generated during the initialization must now be generated after initialization in order to maintain uniqueness.

所以 AWS 有針對 SnapStart 下的 OpenSSL 修正,另外外他們也確認過 Java 的 java.security.SecureRandom 本身就沒問題:

We have updated OpenSSL’s RAND_Bytes to ensure randomness when used in conjunction with SnapStart, and we have verified that java.security.SecureRandom is already snap-resilient.

另外 AWS 也推薦可以直接讀系統的 /dev/random 或是 /dev/urandom,這樣就很自然的不會因為 snapshot 而固定,當然也就沒問題:

Amazon Linux’s /dev/random and /dev/urandom are also snap-resilient.

這個功能說不用另外收費,看起來對 Java 族群還不錯?

Fred Brooks 過世

Hacker News Daily 上看到的消息,Fred Brooks 過世了:

Hacker News 上的討論在「Fred Brooks has died (twitter.com/stevebellovin)」這邊可以翻。

Fred Brooks 是 1999 年的 Turing Award 得主:

For landmark contributions to computer architecture, operating systems, and software engineering.

不過在電腦軟體產業裡,用他另外一個被廣為人知的作品來介紹會比較快,軟體工程的經典書籍「人月神話 (The Mythical Man-Month) (MMM)」的作者,從 Hacker News 的討論串裡面也可以看到很多對 MMM 的討論。

透過 CSS 達到可折疊的 tree view

Hacker News 上看到「Tree views in css」這篇,講怎麼用純 CSS 技巧達到可折疊的 tree view:

主要是用了 ulli 的 html 結構來搭建 tree view 的意義,再透過 <summary><details> 這兩個本身就有 toggle 能力的元素來操作展開與收合,後面就是 visual effects 的設計了。

Can I use 這邊可以看到支援度沒什麼問題 (連 Android 4.4 的 WebView 都支援),除非你還得跟 IE11 奮戰:「Details & Summary elements」。

calloc() 與 malloc() 的差異

前陣子在 Hacker News Daily 上看到的,原文是 2016 的文章:「Why does calloc exist?」,裡面講的東西包括了 implementation dependent 的項目,所以要注意一下他的結論未必適用於所有的平台與情境。

malloc()calloc() 的用法是這樣,其中 calloc() 會申請 countsize 的空間:

void* buffer1 = malloc(size);
void* buffer2 = calloc(count, size);

第一個差異是,count * size 可能會 overflow (而 integer overflow 在 C 裡面是 undefined behavior),這點除非你在乘法時有檢查,不然大多數的行為都還是會生一個值出來。

calloc() 則是會幫你檢查,如果會發生 overflow 的時候就不會真的去要一塊記憶體用。

第二個差異是 calloc() 保證會將內容都設定為 0,這點在 POSIX 的標準裡面是這樣寫的:

The calloc() function shall allocate unused space for an array of nelem elements each of whose size in bytes is elsize. The space shall be initialized to all bits 0.

但作者就發現 malloc() + memset() + free() 還是比 calloc() + free() 慢很多:

~$ gcc calloc-1GiB-demo.c -o calloc-1GiB-demo
~$ ./calloc-1GiB-demo
calloc+free 1 GiB: 3.44 ms
malloc+memset+free 1 GiB: 365.00 ms

研究發現是 calloc() 用了 copy-on-write 的技巧,先把所有的 page 都指到同一塊完全被塞 0 的記憶體,只有在真的寫到該段記憶體時,系統才會要一塊空間來用:

Instead, it fakes it, using virtual memory: it takes a single 4 KiB page of memory that is already full of zeros (which it keeps around for just this purpose), and maps 1 GiB / 4 KiB = 262144 copy-on-write copies of it into our process's address space. So the first time we actually write to each of those 262144 pages, then at that point the kernel has to go and find a real page of RAM, write zeros to it, and then quickly swap it in place of the "virtual" page that was there before. But this happens lazily, on a page-by-page basis.

但畢竟這是 implementation dependent,看看有個印象就好。

用 reprepro 建立 APT repository

在「用 fpm 這個工具包 .deb 安裝」這篇題到了 fpm,另外在同一篇文章裡面 (「Using Cloudflare R2 as an apt/yum repository」這篇) 也有提到要怎麼生出一個有簽名過的 APT repository,裡面就提到了 reprepro 這個工具。

Debian Wiki 上面的「SetupWithReprepro」就有一步一步告訴你設定的方式,另外 Wikimedia 的技術 wiki 上也有提到常用的操作:「Reprepro」。

然後可以丟到很多不同的地方,最常見的 apache 或是 nginx 外,S3 或是其他可以吐 HTTP/HTTPS 的 object storage 服務都可以。

也是先記錄起來,等要用的時候可以回來 blog 上翻到...

Perl 在這十年的效能改善

看到「Perl performance evolution over the last decade」這篇,作者看到大家在講 Python 3.11 的效能改善後,也想看一下 Perl 這邊的效能改善。

作者從 2012 年的 Perl 5.12 開始測,到 2022 年出的 Perl 5.36,最後面的表可以看到大概是 30%:

以十年的跨度來看,30% 成長不怎麼多,但畢竟還是有效能提昇,用很舊的版本的人還是可以考慮昇個級,沒撞到相容性問題的話算是免費的效能提昇。

當年比較驚人的應該還是 PHP 的 5.6 到 7.0,效能差不多是翻倍,讓整個 PHP community 有更多的資源可以用,framework 可以寫的更揮霍一些 XD

用 fpm 這個工具包 .deb 安裝

先前在「Using Cloudflare R2 as an apt/yum repository」這邊看到的工具,其中一個是 fpm,可以快速包裝成各種套件格式 (符不符合 community standard 就是另外一回事晴了)。

在「deb - Debian package format」這邊就有提到像是之前 HashiCorp 都只有丟 binary 出來時,要怎麼打包。

先抓 binary zip 檔下來,然後直接用 fpm 指定版號與要丟的 prefix,他就幫你包起來:

$ wget https://releases.hashicorp.com/terraform/1.0.10/terraform_1.0.10_linux_amd64.zip
$ fpm -s zip -t deb --prefix /usr/bin -n terraform -v 1.0.10 terraform_1.0.10_linux_amd64.zip

生出來的 terraform_1.0.10_amd64.deb 就可以直接 apt install 或是 dpkg -i 裝進去。

看起來可以是個快速先解決問題的工具,之後遇到沒有提供 apt repository 的套件可以用這個方式先打包起來裝,後續移除也比較簡單,不用靠文件來記錄一堆細節...

mosh 1.4.0 出版

去年的時候 mosh 的原作者 Keith Winstein 曾經提過沒有急迫的新版需求 (可以參考「很久沒出新版的 mosh...」這篇),不過剛剛翻資料的時候發現上個月月底出 1.4.0 了:「[mosh-users] mosh 1.4.0 released」,開頭也提到離上次 release 也已經五年了:

The Mosh team is pleased to announce the long-awaited 1.4.0 release. This is our first release in five years and marks ten years since Mosh 1.0.

在 New features 的部份沒有什麼特別的點,對我來說比較有「感覺」的應該是支援 true color 了,但用的情境好像也不算多:

Add true color support (Kang Jianbin)

另外是專案本身的改變,CI 的部份從 Travis CI 搬到 GitHub Actions 上:

Switch from Travis-CI to Github Actions (Wolfgang E. Sanyer, Alex Chernyakhovsky)

好久不見啦...