Month: April 2024

MS-DOS v4.0 的程式碼以 MIT license 釋出

Hacker News 上的消息「Open Sourcing DOS 4 (hanselman.com)」，原文在「Open Sourcing DOS 4」。

Hacker News 裡面的討論有拉出一些有趣的 source code 註解，不過我比較好奇為什麼是挑 v4.0 而不是其他版本，看說明應該是剛好遇到對的人與對的團體？

A young English researcher named Connor "Starfrost" Hyde recently corresponded with former Microsoft Chief Technical Officer Ray Ozzie about some of the software in his collection. Amongst the floppies, Ray found unreleased beta binaries of DOS 4.0 that he was sent while he was at Lotus. Starfrost reached out to the Microsoft Open Source Programs Office (OSPO) to explore releasing DOS 4 source, as he is working on documenting the relationship between DOS 4, MT-DOS, and what would eventually become OS/2. Some later versions of these Multitasking DOS binaries can be found around the internet, but these new Ozzie beta binaries appear to be much earlier, unreleased, and also include the ibmbio.com source.

這些程式碼主要都是考古分析用了，不知道什麼時候 MS-DOS 6.22 的 code 會冒出來...

利用 XOR 處理 time series data 壓縮資料

在「The simple beauty of XOR floating point compression (clemenswinter.com)」這邊看到的內容，原文在「The Simple Beauty of XOR Floating Point Compression」這邊。這也是上一篇文章「Golomb coding」的延續。

文章作者在處理 time series data 時預先用 XOR 處理過 (對上一筆資料做)，因為 time series data 的特性，通常 XOR 出來的結果會有很多都是 0 (表示相同的 bit)，然後再用自己設計的演算法讓 raw data 變小。

以作者拿的第一個範例可以看到變小很多 (開原圖可以看比較清楚)，不過這邊 low bit 都是 0 有點作弊：

後面有 unix timestamp 的部分，這個部分的資料就比較接近實際情況，也可以看出來效果不錯：

這邊似乎也可以選擇套 Golomb coding 或是 Rice coding (i.e. M 是 2 的冪次的特殊情況，2^n，這時候 Truncated binary encoding 剛好就是 Binary encoding)。

算是個有趣的處理法... 不過我猜大多數人為了方便處理，還是只會用 framework 提供的壓縮演算法，在底層透明地處理掉，像是 LZ4、gzip 或是 zstd。

Golomb coding

在 Hacker News 上看到 id=40008133 這篇提到 Golomb coding 覺得很有趣，花了些時間把演算法以及使用的場景搞清楚...

Golomb coding 用在 input 是數字 (或是 fixed size 時硬當作一個數字處理)，而且大多數的資料都偏小的情境下，像是「I don't get Golomb / Rice coding: It does make more bits of the input, or does it?」這邊解釋 Golomb coding 時提到的：

they reduce the average length per encoded value compared to fixed-width encoding, if the encoded values are from a large range, but the most common values are generally small (and hence are using only a small fraction of that range most of the time).

Golomb coding 演算法上用到了兩個特殊的表達方式，Unary coding 與 Truncated binary encoding。

Unary coding 很簡單，把 n 表達成 n 個 bit 的 1，再加上一個 0，所以 3 表達成 1110，7 表達成 11111110。

Unary coding 最主要就是要用到他只用一個 bit 0 來表達 n = 0 的情況。

Truncated binary encoding (中文維基百科剛好有條目：「截斷二進制編碼」) 則是很有趣的一個 encoding 方式。先提到傳統的方式，在表示 n 種可能的組合 (0, 1, ..., n-1) 時，會需要 \lceil\log_2 {n}\rceil bit 表達，像是 n = 5 時，會需要 3 個 bit 表達，從 000、001、010、011 到 100。

Truncated binary encoding 則是找到一個方法，編碼成 00 (對應到 0)、01 (1)、10 (2)、110 (3)、111 (4)，針對 n = 0～2 的部分只用 2 bits 表示，省下 1 個 bit。

Truncated binary encoding 的重點在於在可能性非 2^n 的情況下，要怎麼省儲存空間。

而 Golomb coding 需要預先指定一個 M，對於每一個 x 輸入，拿 M 去除他，就會得到一個商 q 與餘數 r：

x = M * q + r

這邊把商 q 用 Unary coding 表示，餘數 r 用 Truncated binary encoding 表示，就是 Golomb coding 了。

而就如同前面提到的，Golomb coding 會用在資料數字都偏小的情況，當 M 挑的夠好就可以讓 q 常常是 0 或是 10 而省下空間。

這剛好就對到「The simple beauty of XOR floating point compression (clemenswinter.com)」這則提到的東西，在處理 time-series data 時就有機會用這個方式搭配處理...

IBM 買 HashiCorp

居然是 IBM 買 HashiCorp 啊：「IBM to buy HashiCorp in $6.4 billion deal to expand cloud software」。

Red Hat 先前在 RHEL 上面的事情讓 open source community 頗感冒，加上 HashiCorp 先前切到 BSL (先前有提到的：「HashiCorp 將放棄 Open Source License，改採用 BSL 1.1」)，看起來差不多有個概念了？

另外 IBM 這邊官方新聞稿在這：「IBM to Acquire HashiCorp, Inc. Creating a Comprehensive End-to-End Hybrid Cloud Platform」。

Simon Tatham 的遊戲庫

在 Hacker News 上看到「Simon Tatham's Portable Puzzle Collection (greenend.org.uk)」這個討論，會讓我注意到的點是看到 greenend.org.uk 這個網址，印象中這就是 PuTTY 官網用的 domain，而點進去看以後發現就是 PuTTY 作者 Simon Tatham 另外的小玩具：「Simon Tatham's Portable Puzzle Collection」。

裡面都是單人遊戲，有提供 JavaScript 版可以在瀏覽器上直接玩，另外也有多個不同平台的執行檔可以用。是個墮落殺時間的區域...

北韓的動畫承包團隊

2023 年的時候在北韓的 internet 上發現一台沒有設定好的伺服器，於是就有人 dump 下來分析裡面的內容，然後就發現看起來是中國的團隊轉包給北韓團隊用的 server：「What We Learned Inside a North Korean Internet Server: How Well Do You Know Your Partners?」。

像是這張圖，可以看到上面有「EKACHI EPILKA」，這查一下可以查到「株式会社エカチエピルカ」，另外也可以看到簡體中文以及韓文的說明：

雖然拼圖不夠完整，但應該是可以看出輪廓了：目前比較像的情況應該是中國拿到合約後轉包給北韓的團隊，這對於有在關注日本動畫產業的人來說應該也不算太意外，日本的動畫產業已經是高度分工，自己國家內二包三包本來就很常見，如果是先包到中國，再分包到北韓的話也不算太奇怪：

There is no evidence to suggest that the companies identified in the images had any knowledge that a part of their project had been subcontracted to North Korean animators. In fact, as the editing comments on all the files, including those related to US-based animations, were written in Chinese, it is likely that the contracting arrangement was several steps downstream from the major producers.

不過法律上就有些狀況了，北韓應該是被制裁對象...

在 virt-manager 裡面的 Windows 發出聲音

用了幾個月才發現沒聲音，花了點時間找方法測試才解決。

一般人用預設值應該是沒問題，不過我的環境比較特別，剛好不是預設值，我的 PulseAudio 輸出到 DA&T C-13 時是設定成 96kHz/24bit，而一般 Windows 預設輸出時是 44.1kHz/16bit，兩邊對不起來就沒聲音了。

找了一些文章，後來是在「Virtual machine audio setup – or how to get pulse audio working」這篇裡面講到用 virsh 直接改 XML 設定檔的方式讓 qemu 輸出到 PulseAudio 裡面轉，也就是文章裡面 Option 2 的部分。

這樣 guest OS 裡面還是跑 44.1/16，但外面輸出的時候就固定是 96/24 了。

比較奇怪的是如果 guest 裡面跑 96/16 的話聲音會破破的，不過我只是要有聲音 (不然也不會用了好幾個月才發現)，品質的問題倒是還好...

更激進的考慮使用者會混淆的問題

前陣子寫的「UUID 的 UX」考慮到了人眼會把 0Oo 以及 1IiLl 看錯的問題，這篇則是更激進的想辦法去避免類似的問題：「Understanding and avoiding visually ambiguous characters in IDs」，對應的討論可以在「Understanding and avoiding visually ambiguous characters in IDs (gajus.com)」這邊看到。

作者有提到，這是用在人類需要寫下或是溝通時，避免錯誤的發生：

Any time that the ID might need to be communicated verbally or written down[.]

這就不只是前面提到的 0Oo 與 1IiLl 問題了，包括看起來有機會誤會的字，像是 2Z 以及 8B 這種也要避開。

如果是大小寫都放進去的話是 53 個字可以用，但如果希望大小寫意思一樣的話就只剩下 22 個字可以用了：

Assuming that you are going with case sensitivity, you have 53 characters to choose from (adjusted for visually ambiguous characters). On the other hand, if you decide to make your IDs case-insensitive, you have only 22 characters to choose from.

他給出了這 22 個字：

[
  "a",
  "b",
  "c",
  "d",
  "e",
  "f",
  "h",
  "i",
  "j",
  "k",
  "m",
  "n",
  "o",
  "p",
  "r",
  "s",
  "t",
  "w",
  "x",
  "y",
  "3",
  "4"
]

後續還提到 rn 與 m，以及 vv 與 w 的相似問題，不過這邊的 generator 就更難搞了...

搞到這樣，乾脆用數字就好？使用者的 UX 也比較好？

Python 2.7 的延伸支援

Python 2 在大約四年前 2020/04/18 推出了最後一版 Python 2.7.18 後，後續的安全性更新就變成要找第三方支援了。

在 2023/09 出的 Trac 1.6 總算是換到 Python 3 後，手上就沒有遇到要用 Python 2.7 的東西了...

剛剛在「PyPy v7.3.16: release of python 2.7, 3.9, and 3.10」這邊看到跟 Python 2.7 有關的消息，一時興起翻了翻有哪些延長的商業支援可以買，看起來有兩個：

真的遇到的話再來寫信問問看好了...

LLL lattice basis reduction algorithm

短短幾天內看到兩個不同的地方用到了 1982 年發現的「Lenstra–Lenstra–Lovász lattice basis reduction algorithm」。

第一個是「Randar: A Minecraft exploit that uses LLL lattice reduction to crack server RNG (github.com/spawnmason)」這篇，作者群利用 LLL 去分析 java.util.Random 的內部狀態，進而得到其他玩家的地點資訊：

Every time a block is broken in Minecraft versions Beta 1.8 through 1.12.2, the precise coordinates of the dropped item can reveal another player's location.

"Randar" is an exploit for Minecraft which uses LLL lattice reduction to crack the internal state of an incorrectly reused java.util.Random in the Minecraft server, then works backwards from that to locate other players currently loaded into the world.

另外一個是在 Hacker News 上面的 id=40080651 提到，前幾天 PuTTY 的 p521 問題在底層也用到了 LLL：

LLL lattice reduction is the same algorithm that can be used for cracking PuTTY keys from biased nonces from the CVE a few days ago. 'tptacek explained a bit about the attack (and links to a cryptopals problem for it, which I can almost pretend to understand if I squint) https://news.ycombinator.com/item?id=40045377

從維基百科的內容也可以看出來 application 非常多，不光是密碼學的領域用到，看起來值得花點力氣來了解...