兩個 unsigned int 取平均值的方法

Hacker News Daily 上看到 Raymond Chen 在講怎麼對兩個 unsigned int 取平均值的方法:「On finding the average of two unsigned integers without overflow」,這篇裡面提到了不少有趣的歷史,另外 Hacker News 上的討論「Finding the average of two unsigned integers without overflow (microsoft.com)」也可以翻翻。

最直覺的解法會有 overflow 的問題:

unsigned average(unsigned a, unsigned b)
{
    return (a + b) / 2;
}

如果已知 a 與 b 的大小的話 (如同作者說的,蠻多時候都符合這個情況),可以用這個方法避免 integer overflow:

unsigned average(unsigned low, unsigned high)
{
    return low + (high - low) / 2;
}

另外還有個方法是有專利的 (「Calculating the average of two integer numbers rounded towards zero in a single instruction cycle」),雖然在 2016 年到期了,各除以二相加後,只有 ab 都是奇數的情況下需要補 1:

unsigned average(unsigned a, unsigned b)
{
    return (a / 2) + (b / 2) + (a & b & 1);
}

接下來的這個方法用 AND 與 XOR 搞事,其中的原理可以解釋成,相同的 bit 不動表示值不需要動,不同的 bit 表示降一位 (除以 2):

unsigned average(unsigned a, unsigned b)
{
    return (a & b) + (a ^ b) / 2;
}

最後是暴力解,用個比較大的 data type 搞定他:

unsigned average(unsigned a, unsigned b)
{
    // Suppose "unsigned" is a 32-bit type and
    // "unsigned long long" is a 64-bit type.
    return ((unsigned long long)a + b) / 2;
}

後面有很多 assembly 的妖魔鬼怪跑出來就不提了 XDDD

Laravel 9 (LTS) 出了

剛剛看到 Laravel 9 (LTS) 出的消息:「Laravel 9 is Now Released!」,對應的 release notes 在「Release Notes」這邊可以看。

相隔兩年半的 LTS 版本,另外也要求到 PHP 8.0+:

不過 Lavavel 的 LTS 設計上,沒有與一般 release 差太多,LTS 版本是 24/36 個月支援 (功能/安全),但一般版本是 18/24 個月支援:

For LTS releases, such as Laravel 9, bug fixes are provided for 2 years and security fixes are provided for 3 years. These releases provide the longest window of support and maintenance. For general releases, bug fixes are provided for 18 months and security fixes are provided for 2 years.

如果看隔壁 Ubuntu 的 LTS 是 60 個月,但一般版本是 9 個月;Node.js 的 LTS 是 36 個月,以及一般版本的 9 個月,這樣看起來就有很明顯的差異...

這樣看起來跟一般版本好像也還好?

PostgreSQL 15 將可以對透過 UNIQUE 限制 NULL 的唯一性了

看到「Waiting for PostgreSQL 15 – Add UNIQUE null treatment option」這篇文章裡面提到 PostgreSQLUNIQUE 多加了一些功能進去:「Add UNIQUE null treatment option」。

The SQL standard has been ambiguous about whether null values in unique constraints should be considered equal or not.  Different implementations have different behaviors.  In the SQL:202x draft, this has been formalized by making this implementation-defined and adding an option on unique constraint definitions UNIQUE [ NULLS [NOT] DISTINCT ] to choose a behavior explicitly.

This patch adds this option to PostgreSQL.  The default behavior remains UNIQUE NULLS DISTINCT.  Making this happen in the btree code is pretty easy; most of the patch is just to carry the flag around to all the places that need it.

The CREATE UNIQUE INDEX syntax extension is not from the standard, it's my own invention.

I named all the internal flags, catalog columns, etc. in the negative ("nulls not distinct") so that the default PostgreSQL behavior is the default if the flag is false.

Reviewed-by: Maxim Orlov 
Reviewed-by: Pavel Borisov 
Discussion: https://www.postgresql.org/message-id/flat/84e5ee1b-387e-9a54-c326-9082674bde78@enterprisedb.com

以往針對某個欄位下 UNIQUE 後,雖然同樣的值是無法 INSERT 進去,但 NULL 則是個例外,是可以塞多次進去的。

現在則是提供選項指定對 NULL 的解讀了;預設還是保留原來行為的 UNIQUE NULLS DISTINCT (把每個 NULL 都當作不同的值看待),特別指定後會變成 UNIQUE NULLS NOT DISTINCT (把每個 NULL 都當作一樣的值,進而被 UNIQUE 條件限制)。

在下一個版本的 PostgreSQL 15 就會出現這個功能了...

Raspberry Pi OS 64-bit 與 32-bit 的效能差異

前幾天提過「Raspberry Pi OS 64-bit 版本正式推出」,而 Phoronix 實際拿正式版測試 64-bit 與 32-bit 的系統差異了,在「Raspberry Pi OS 32-bit vs. 64-bit Performance」這邊可以看到每一個測試項目的結果。

測試的硬體是 Raspberry Pi 400,這台機器基本上就是 4GB 版本的 Raspberry Pi 4 加上週邊配件:

Using a Raspberry Pi 400 keyboard computer with 4GB of RAM, I ran some fresh benchmarks of Raspberry Pi OS in its default 32-bit build and then again with the new 64-bit build.

先講結果,在 Phoronix 的 33 個測試裡面,64-bit 全部都比 32-bit 好,而且是很明顯的差異:

Across the few dozen different workloads tested, switching Raspberry Pi OS 11 for the 64-bit version improved the performance on average by about 48%. See all the 32-bit vs. 64-bit Raspberry Pi benchmarks over on OpenBenchmarking.org.

之前 64-bit OS 還在 beta 的時候就已經知道這個情況了,所以不會覺得太意外。當時提出的解釋是指令集的差異,aarch64 提供的指令集比 armv6 有效率多了,這點在 2016 年的文章「64-bit ARM (Aarch64) Instructions Boost Performance by 15 to 30% Compared to 32-bit ARM (Aarch32) Instructions」這邊可以看到說明。

所以正式版出來以後,只要硬體有支援,基本上都建議裝 64-bit OS 了...

PHP: The Right Way

Hacker News 上面意外看到「PHP – The Right Way (phptherightway.com)」,官網在「PHP: The Right Way」這邊,另外我在 2012 年的時候也有提過這個站台:「PHP 康莊大道」。

看了一下,應該不完全是給初學者看的,反而對於回鍋的人比較有用,無論是很舊的歷史 (像是裡面提到的 PEAR),還是比較新的東西 (像是 test case 那邊的介紹),他都有花一些篇幅介紹,而且除了開發以外也包含了 deployment 與 hosting provider 的部份...

沒想到這個網站過了十年繼續維護啊,而且內容豐富不少...

Raspberry Pi OS 64-bit 版本正式推出

Twitter 上看到前同事貼了 Raspberry Pi 官方放出 Raspberry Pi OS 64-bit 版本的公告:「Raspberry Pi OS (64-bit)」。

我是在 beta 時就已經跑一陣子了,依照官方的說明可以看到 Raspberry Pi 3 或是 Raspberry Pi Zero 2 以上的版本才支援 64-bit OS。

我是在 Raspberry Pi 3 上面跑,主要是現在大多數支援 ARM 指令集的 package 都是包 arm64,換到 64-bit OS 能裝的東西會比較多。

另外有提到目前 64-bit 版本的 Chromium 還沒有 Widevine 支援,無法看 Netflix 或是 Disney+,需要裝 32-bit 版本才能看:

The 64-bit version of Chromium, installed by default, has no version of the WidevineCDM library and therefore, it is not possible to play streaming media such as Netflix or Disney+.

不過應該過一陣子就會有了...

一些不太容易注意到的 Python 安全性問題

前幾天看到「10 Unknown Security Pitfalls for Python」這篇,講 Python ecosystem 裡面的一些設計造成的安全性問題,裡面很多東西都很有趣,而且有些算是共通的,其他程式語言也會中獎...

第一個是開發者用 assert() 確認權限,但 assert() 的設計是 debug 用的功能,所以可以預期在 optimization 後會被拿掉 (其他程式語言也有類似的功能),而導致權限沒被檢查而產生 security incident。

第二個是 os.makedirs() 所指定的 mode,依照說明看起來是 Python 改變行為了,變成只有最終的那個目錄照著設定:

In Python < 3.6, the folders A, B and C are each created with permission 700. However, in Python > 3.6, only the last folder C has permission 700 and the other folders A and B are created with the default permission 755.

這個設計就有點討厭了,我測了一下 umask 077 的情況下在 shell 下執行 mkdir a/b/c,所有的目錄都會是 700

第三個是串檔名的 os.path.join(),遇到 / 開頭的部份會把前面的部份都拔掉,也就是這樣:(嗯... 這樣搞的嗎 XDDD)

>>> os.path.join('var', 'lib', 'tmp', 'abc.png')
'var/lib/tmp/abc.png'
>>> os.path.join('var', 'lib', 'tmp', '/etc/shadow')
'/etc/shadow'

第四個就是蠻標準的 variable injection 了。

第五個算是每次處理 .zip 檔都很頭痛的問題,不限於 Python,因為壓縮檔裡面可能會有 ../../ 開頭這種看起來就很邪惡的檔案名稱,只要有安全意識的工程師都覺得處理起來很麻煩的東西...

第六個一看就是壞東西,想要用黑名單擋 injection 一定會有更多有創意的方法打進來。比較特別的是這邊有提到在 Python 裡 re.search()re.match() 的差異,這點真的是寫起來有時後會忽略掉的...

第七與第八個都是 Unicode 相關的問題,也是個超級麻煩的東西,大原則是先 normalize 再 escape,但還是有點見招拆招去看...

第九個也是類似的問題,沒有先 normalize 再確認,不過一般機器都會有 private ip address,還是可以試著打... 這個有機會用架構面去解決,像是用 MQ 架設 proxy service,隔出另外一區來跑;或是已經有 zero trust 的架構,內部網路也是要帶 token 跑來跑去,可以減少一些傷害...

第十個算是 Python 自己的歷史因素,早期同時吃 &; 當作 separator,而非只吃 &x-www-form-urlencoded (HTML spec 內定義的標準):

In Python < 3.7 the function urllib.parse.parse_qsl allows the use of the ; and & characters as separators for URL query variables.

查了一下官方文件可以看到 3.10 之後才變成 x-www-form-urlencoded

Changed in version 3.10: Added separator parameter with the default value of &. Python versions earlier than Python 3.10 allowed using both ; and & as query parameter separator. This has been changed to allow only a single separator key, with & as the default separator.

有些應該是有安全意識時會去翻 spec 看看就可以避開的,但有些就真的是蠻雷的 XDDD

Backblaze 的 2021 年硬碟死亡報告

Backblaze 放出 2021 年的硬碟統計數據了:「Backblaze Drive Stats for 2021」。

最後一張圖是 Backblaze 機房內還活著的硬碟資訊,大概是整篇裡面最有用的 (而且有 AFR 的信心區間),先拉出來看:

比較好奇的是還沒有導入 18TB 的硬碟...

另外從上面依照廠牌分類的部份也可以看出個感覺,這時候如果再針對各廠牌的歷史記錄拉出圖的話就很殘酷了,要說 Seagate 不愧是 Seagate 嗎 (大家的刻板印象好像也不刻板了,數字都對的上...):

如果就廠牌可以看出來 HGST 不論哪個型號,死亡率 (AFR) 都很低,而 Toshiba 與 Seagate 則是很吃型號,有的型號 AFR 很高,但有的就蠻低的...

另外裡面有提到一個比較有趣的現象,大顆硬碟的 AFR 反而比較低,目前猜測是新硬碟的關係,但時間要拉長才會看的比較明顯,不確定是不是有什麼技術發展出來 (過個幾年再回來看的意思):

話說前陣子才送修一顆 Seagate 的硬碟回來 (還在保固內),SMR 的死亡率果然高不少...

MariaDB Corporation Ab 透過 SPAC 上市

MariaDB Corporation Ab 透過 SPAC 上市:「MariaDB Corporation Ab to Become a Publicly Traded Company via Combination with Angel Pond Holdings Corporation」。

Upon closing of the transaction, the combined company will be named MariaDB plc and led by MariaDB’s CEO Michael Howard.

Hacker News 上有一些對 MariaDB 的討論可以看一下 (是對軟體討論,不是對公司討論):「MariaDB to go public at $672M valuation (mariadb.com)」。

大多數用 MariaDB 的人其實都只是在用 MySQL 的功能,不常用到 MariaDB 的特殊功能,像是 Aria (MyISAM 的 crash-safe 版本) 還是沒有 transaction,而 InnoDB 的效能其實相當好,就找不太到理由去用 Aria...

另外從 Google Trends 的 volume 也可以看出來趨勢是往下降而非向上爬升,這時候趕快脫手 (而且還是透過 SPAC) 看起來是最好的時機?

紐約時報買 Wordle...

Hacker News 上看到「The New York Times Buys Wordle」這篇,紐約時報買下 WordleHacker News 上的討論「The New York Times buys Wordle (nytimes.com)」裡面有在討論商業模式之類的事情,另外因為紐約時報的報導放在 paywall 裡面,所以另外提供 Internet Archive 的版本可以看:「The New York Times Buys Wordle」。

這邊就不介紹 Wordle 了,在中文版的維基百科上面有條目可以看說明:「Wordle」,玩過幾天後我就放掉了...

紐約時報買 Wordle 的價錢沒有詳細透露,只有說大約是 million 等級的價錢:

Wordle was purchased from its creator, Josh Wardle, a software engineer in Brooklyn, for a price “in the low seven figures,” The Times said. The company said the game would initially remain free to new and existing players.

但後續的動作就不知道了,也許是整合 word puzzle,也許是藉此延伸 social network?