Software – Page 6 – Gea-Suan Lin's BLOG

紐約時報早期的 Flash 圖表使用 Ruffle 執行

剛好上一篇才在講 Ruffle，結果看到「New York Times Flash-based visualizations work again (flowingdata.com)」這邊的討論才發現紐約時報也開始用 Ruffle 呈現早期的報導裡面的 Flash 圖表了：「NYT Flash-based visualizations work again」，這篇文章裡面則是引用了「The New York Times now has a web Flash player」。

文章裡面給了好幾個範例頁面，像是「The Ebb and Flow of Movies: Box Office Receipts 1986 — 2008」這個，我用桌機開起來的時候 CPU 也是狂操了一陣子才跑出來，而且操作起來有點卡，但至少有東西繩線出來可以用...

Ruffle 對 crossdomain.xml 的處理方式

ruffle 是一個 open source 的 Flash 模擬器，用 JavaScript (以及 WebAssembly) 讓使用者可以在瀏覽器裡面直接執行。

不過想到 Flash 的 crossdomain.xml 在技術上應該是沒辦法繞過瀏覽器對 CORS 的限制，所以找了一下目前的情況... 在「Ideas for getting arounds CORS restrictions #8972」這邊有提到兩個方法，另外 comment 提到了「Add setting to spoof URLs in network requests #1486」這個。

看起來這個問題還在「有點子，但沒解決」的情況。

不過找了一下當年有玩的小遊戲 Zookeeper，在「Zookeeper - Flash Games Archive | FlashArch」這邊可以玩，看起來功能都還算正常，讓人懷念啊...

把文字檔壓成 PNG 跟 Gzip 比較壓縮率

Hacker News 上看到「Compressing Text into Images (shkspr.mobi)」這個奇怪的方法，是把文字轉成灰階的 PNG 檔案，然後跟 ZIP 比較壓縮率，居然是能打的。原文則是在「Compressing Text into Images」這邊。

這是屬於週末奇怪的 side project，作者也覺得這樣很白爛 XDDD

(This is, I think, a silly idea. But sometimes the silliest things lead to unexpected results.)

作者是拿羅密歐與茱麗葉的小說當資料 (Romeo and Juliet)，這可以在 Project Gutenberg 的網站上下載到 txt 檔案。

基本的想法是把每個文字轉成灰階圖片的像素，然後用 PNG 無損輸出，最後再用 Squoosh 處理：

The English language and its punctuation are not very complicated, so the play only contains 77 unique symbols. The ASCII value of each character spans from 0 - 127. So let's create a greyscale image which each pixel has the same greyness as the ASCII value of the character.

結果居然是跟一般的壓縮軟體差不多：

That's down to 55KB! About 40% of the size of the original file. It is slightly smaller than ZIP, and about 9 bytes larger than Brotli compression.

我試著驗證作者的想法，用 Go 寫了個小程式輸出操作圖片，產稱一張寬度是小說的 byte 數，高度只有 1 的 PNG 檔輸出，最後再用 pngcrush 處理：「gslin/text-to-image-compression」。

另外我是與 gzip 比較 (原作者是與 ZIP 比較)，結果是：

PNG: 64379
Gzip: 64563
Gzip (-9): 64331

的確是差不多的等級？

用 x86 組語寫的 web forum

另外一個在週末看到的奇怪東西，用 x86 組語寫的 web forum：「AsmBB – a lightweight web forum engine written in assembly language (asmbb.org)」，官網在 asmBB 這邊，說明則是在「What is AsmBB?」這頁。

是個 x86 assembly + SQLite 的組合：

AsmBB is fully written in assembly language and uses SQLite as a database back-end. That is why it can work on really weak hosting and in the same time serve huge amount of visitors without lags and delays.

程式碼是用 Fossil 管的，不過作者有 mirror 到 GitHub 上：「johnfound/asmbb」。

SQlite 的部分用了 SQLeet，可以在 sqleet.inc 這個檔案裡面看到引用了 libsqleet.so：

AsmBB uses SQLite with SQLeet extension as a back-end storage database and FastCGI interface to the web server.

組語的部分看起來是用 fasm 寫的，看程式碼 (像是 encryption.asm) 可以看到一些好用的語法，像是自動處理 function 參數的部分 (應該有設定某種 convention)，跟當年寫 MASM 的用法方便不少：

stdcall TextCreate, sizeof.TText
mov     edx, eax

stdcall TextCat, edx, <"Content-type: text/html; charset=utf-8", 13, 10, 13, 10>
stdcall RenderTemplate, edx, 'crypto.tpl', 0, esi

用 shebang 掛起 Docker instance

週末偶而會看到一些奇怪的 side project，像是用 shebang (#!) 直接跑起一個 Docker instance 的方式：「Show HN: #!/usr/bin/env docker run (gist.github.com)」，程式碼在 gist 上：「adtac/595b5823ef73b329167b815757bbce9f」。

可以看到裡面主要的內容都是 Dockerfile，然後重點在開頭的 shebang command，把這些 Dockerfile 的指令倒進去跑 docker build：

#!/usr/bin/env -S bash -c "docker run -p 8080:8080 -it --rm \$(docker build --progress plain -f \$0 . 2>&1 | tee /dev/stderr | grep -oP 'sha256:[0-9a-f]*')"

記得這邊處理後面參數的部分有 undefined behavior，在 id=38989173 這邊也有人提到了：

Beware of portability: it relies on a non-standard behavior from some operating systems. It only works on OSs that treat all the text after the first space as argument(s) to the shebanged executable; rather than just treating the whole string as an executable path (that can happen to contain spaces).

但這主要是好玩，也就還好了...

各家瀏覽器與工具對於 blur 效果的實際呈現比較

在 Hacker News 上看到「Blur Radius Comparison (bjango.com)」，原文在「Blur radius comparison」。

重點在這張：

前面九個分成三種效果在三個不同的瀏覽器呈現的結果，然後是 Figma、Illustrator、Photoshop 與 Sketch 的效果。

可以看出來在瀏覽器上的部分，大家的 rendering 沒有差太多。

而 Figma 所有 blur 類的效果，在瀏覽器上比較接近的只有 box-shadow，其他三套則是有不同的變化...

觀察 Docker image 每一層變化的 dive，以及操作的 crane

在「Dive: A tool for exploring a Docker image, layer contents and more (github.com/wagoodman)」這邊看到的工具，官網在 GitHub 上：「wagoodman/dive」。

Docker image 是一層一層疊起來的，而 dive 可以翻出每一層的變化：

A tool for exploring a docker image, layer contents, and discovering ways to shrink the size of your Docker/OCI image.

馬上想得到的用途是拿來分析空間的使用情況，另外可以拿來確認 container 裡面的內容 (就不用 /bin/bash 進去看了)。

在留言 id=38915336 這邊另外提到了 crane 這個有趣的的東西，可以操作 Docker image。

這邊看到的說明包括了合併不同的 layer，以及類似 Git 的 rebase 功能 (re-apply diff)：

For image and layer manipulation, crane is awesome - as is the underlying go-containerregistry library.

It lets you add new layers, or edit any metadata (env vars, labels, entrypoint, etc) in existing images. You can also "flatten" an image with multiple layers into a single layer. Additionally you can "rebase" an image (re-apply your changes onto a new/updated base image). It does all this directly in the registry, so no docker needed (though it's still useful for creating the original image).

https://github.com/google/go-containerregistry/blob/main/cmd/crane/recipes.md

(updated: better link)

兩個剛好搭在一起...

systemd 的問題

在 Lobsters 的「systemd through the eyes of a musl distribution maintainer」這篇看到的，隔壁 Hacker News 的「Systemd through the eyes of a musl distribution maintainer (catfox.life)」也可以參考，原文在則是「systemd through the eyes of a musl distribution maintainer」這邊。

裡面提到的幾個痛點算是社群的共識了，像是負責 DNS 的 systemd-resolved，我之前有寫「Ubuntu 20.04 下用 resolvconf 取代 systemd-resolved (因為 PPPoE)」這個，回頭去用 resolvconf 支援度比 systemd-resolved 好很多。

另外一個社訊的共識是 systemd 多做了很多不屬於他的事情，像是跑去處理網路 (systemd-networkd)，或是 NTP client (systemd-timedated)，處理得很半吊子...

但偏偏市占率大的 distribution 都跳過去用 systemd，而 OpenRC 只有少數幾個 distribution 在用，佔有率差太多...

世紀帝國系列裡的 AoE 與 AoK 使用組合語言加速的情況

Age of Empires (1997) 與 Age of Empires II: The Age of Kings (1999) 是當年兩個很紅的遊戲，有傳言裡面有很大一部分是用組合語言寫的。

剛剛在 Hacker News 上看到「Original Age of Empires 2 dev talks about its usage of assembly code (reddit.com)」這篇，看起來是原作者跳出來說明這段傳言 (講的更細)，原文在 Reddit 的「AoE is written in Assembly - is this actually TRUE?! :O : aoe2」這邊。

32-bit 的 x86 組語部分有大約 13k 行，大多數 (11.5k 行) 是與繪圖有關的 (當年繪圖相關的功能都還是 CPU 在算)：

There were about ~13,000 lines of x86 32-bit assembly code written in total.

The vast majority, about ~11,500 lines worth, was in the 'drawing core', which drew SLP sprites in a variety of ways (mirrored, stippled, clipped). The code for this was in a separate .asm file, which was "compiled" by Microsoft Macro Assembler 6.1 into a .obj file.

最主要的目的當然是效能，這邊提到隔壁棚的星海爭霸預設還是 640x480 的時候，AoE 這邊預設可以上 800x600：

The use of assembly in the drawing core resulting in a ~10x sprite drawing speed improvement over the C++ reference implementations, and AoE's drawing core was notably faster than competitors like StarCraft, which is why the default resolution 'out of the box' for AoE was 800 by 600, when nearly all our competition was 640 x 480 resolution - we could scroll the screen and fill it with sprites as fast or faster even though we had twice as many pixels-ish in the game world area.

後來到 64-bit 年代就變成用 C++，主要是因為 compiler optimization 的改進，以及多 CPU 與 multi-threading 的技術，讓計算力提升很多：

I re-wrote the assembly functions into C++ for both Definitive Editions, as they are 64-bit programs, and inline assembly was never supported by the 64-bit C++ compiler, and the vastly improved register sets and compiler optimizations made it un-necessary. Additionally, sprite drawing in the definitive editions is multi-threaded, and will use up to 4 cores for that task alone.

算是時代的演進，意外的留下一些記錄... 而更後面的時代則是把這些計算 offload 到顯卡上面了。