用 TeX 寫數學公式時常見的錯誤與解法

Hacker News 上看到「The Art of LaTeX: Common mistakes and advice for typesetting proofs (fanpu.io)」,原文在「The Art of LaTeX: Common Mistakes, and Advice for Typesetting Beautiful, Delightful Proofs」這,在講用 TeX 寫數學公式時常見的錯誤 (以及正確的寫法)。

裡面給了蠻多還蠻實用的提醒,像是第一點提出來的這兩個差異:

以及:

上面是用最單純的 {( 寫的,要達到下面比較正確的效果,不應該用 \bigl 這種直接指定括弧大小的用法,而是用 \left( 這種告訴 TeX 排版引擎這邊的意義,然後算出需要拿多大的括弧出來用。

畢竟 TeX 是 Knuth 老人家弄出來的東西,你會看到很多設計是需要給 TeX 排版引擎正確的定義或是資訊,剩下的他就會幫你處理...

KataGo 1.12.0 與 UEC 杯用的 model:b18c384nbt-uec.bin.gz

剛剛看到 KataGo 出了 1.12.0,同時也放出了在 2022 年十一月 UEC 比賽時用的 model:「New Neural Net Architecture!」。

1.12.0 比較特別的新的類神經網路架構:

This version of KataGo adds support for a new and improved neural net architecture!

這個新的架構以及其他的改善讓訓練的速度改善:

The new neural nets use a new nested residual bottleneck structure, along with other major improvements in training. They train faster than KataGo's old nets and learn more effectively.

另外一個是他把 UEC 比賽時用的 model 放出來了,很特別的是採用 b18c384,而 KataGo Distributed Training 這邊目前主要是 b40c256 與 b60c320,看起來是為了比賽而一次性訓練出來的。

依照他的說法這個 b18c384 版本跟目前訓練網站上的 b60c320 有差不多強度,但計算速度會比 b60c320 快不少,甚至在一些機器上會跟 b40c256 差不多快:

Attached to this release is a one-off net b18c384nbt-uec.bin.gz that was trained for a tournament in 2022, which should be of similar strength to the 60-block nets on http://katagotraining.org/, but on many machines will run much faster, on some machines between 40-block and 60-block speed, but on some machines even as fast as or faster than 40-block.

另外一個大改變是他把訓練工具從 TensowFlow 跳槽到 PyTorch

The training code has been all rewritten to use pytorch instead of tensorflow.

在 release note 裡沒有提到原因,但這個頗讓人好奇的...

fp32、fp16 與 bf16

nanoGPT 這個專案下面看到 bf16 這個浮點格式:(這段在新版的 README.md 被改寫了)

Currently fp16 is much faster than bf16. Potentially revert back to using fp16 and re-introduce the gradient scaler?

翻了一下 bf16,是由 Google 的團隊所提出來的想法,主打是與 fp32 相同的表示範圍,但是犧牲精度,這樣一來既有使用 fp32 的程式很有機會可以直接換成 bf16 降低計算量 & 提昇效率 (也就是 drop-in replacement):

然後同一頁也看到各家自己推出不同的格式,這邊看起來比較像是市場競爭的關係...

Debian 移除 Python 2 套件

Hacker News 首頁上看到 Debian 移除 Python 2 的消息:「Python 2 removed from Debian (debian.org)」,對應的 ticket 在這邊:「#1027108 - RM: python2.7 -- RoQA; Obsolete - Debian Bug report logs」。

Python 2 從 2015 年喊 EoL 喊很久,終於在 2020/04/20 發行最後一版 Python 2.7.18

大多數的套件應該都有 Python 3 的支援了,有需要的人 (像是還是沒支援 Python 3 的 Trac) 可以透過 pyenv 建立 Python 2 的環境出來跑,或是丟進 Docker 裡面跑。

銀河的歷史又翻過了一頁...

資料庫在 2022 年的發展

Hacker News 上看到這篇對 2022 年資料庫發展的回顧文章,可以補一些沒看到的新聞與發展:「Databases in 2022: A Year in Review」,作者 Andy PavloOtterTune 的創辦人,有些他的想法會有些偏見,就當作一方之言來看就好。另外在 Hacker News 上的討論則是冒出一堆創辦人出來替自己公司的產品介紹一番:「Databases in 2022: A Year in Review (ottertune.com)」。

首先是他提到的 ClickHouse,我是 2022 年才開始關注,而且發現很不賴。查了一下維基百科,在 2021 年十月的時候搞了 round B $250m,估值 $2b:

On October 28, 2021 the company received Series B funding totaling $250 million at an valuation of $2 billion from Coatue Management, Altimeter Capital, and other investors.

另外是 Meta 弄出來的 Velox,直接看官網上面的圖可以看到,他試著把 Database、PrestoSpark 的 engine/worker 層抽換掉:

GitHub 的頁面說明上也可以看出來,Velox 是提供很多已經最佳化過的界面 (包括了 Type、Vector、Expression Eval、Function Packages、Operators、I/O、Network Serializers 與 Resource Management) 讓 engine/worker 直接使用,避免了自己的實做沒有最佳化:

Velox is a C++ database acceleration library which provides reusable, extensible, and high-performance data processing components.

In common usage scenarios, Velox takes a fully optimized query plan as input and performs the described computation. Considering Velox does not provide a SQL parser, a dataframe layer, or a query optimizer, it is usually not meant to be used directly by end-users; rather, it is mostly used by developers integrating and optimizing their compute engines.

其他的消息就看過去有個印象...

Git 在 SHA-256 支援上遇到的問題

在 Hacker News 首頁上的「Whatever happened to SHA-256 support in Git?」這篇,大概半年前,今年六月的文章,在講 GitSHA-256 支援上遇到的問題。

最大的問題還是沒有 transition plan:

Bjarmason pointed out that there is still no interoperability between SHA-1 and SHA-256 repositories, and that none of the Git hosting providers appear to be supporting SHA-256.

這點導致了目前場上看的到的服務與 open source 軟體都沒有支援的計畫,這點算是一個超級失敗的 transition plan。

另外乾脆請 OpenAIChatGPT 幫忙寫:

Git是一種源代碼管理系統,它使用散列函數將每個對象(例如文件的每個版本)和每個提交都轉換為一個數值,用於存儲該對象。散列函數的安全性是整個倉庫完整性的重要組成部分。如果攻擊者可以用具有相同散列值的另一個提交替換提交,他們可能會在不冒檢測風險的情況下將惡意代碼植入倉庫中。這種前景令任何依賴 Git 倉庫中代碼安全性的人感到擔心,也就是所有人。

Git 項目早已選擇 SHA-256 作為 SHA-1 的替代品。Git 最初是使用 SHA-1 寫成的,但是這些代碼已被重構,並且可以處理多種散列類型,其中 SHA-256 是第二種支持的類型。現在可以使用 SHA-256 創建 Git 倉庫(只需使用 --object-format=sha256 標誌),大多數本地操作都會正常工作。Git 中支持替代散列算法的基礎是2020年發布的2.29版本的一部分,並且似乎很穩定。

然而,自從2021年3月發布的2.31版本中出現了修復程序以來,2.29版本是最後一個在任何重大方面支持替代散列的版本。專

續寫前文,Git 專案在支持 SHA-256 之前一直使用 SHA-1 作為散列算法。然而,由於 SHA-1 的終極破解,Git 項目被迫尋找替代方案。Git 原本的代碼是深深地嵌入 SHA-1 的,但是這些代碼已經被重構,並且可以處理多種散列類型,其中 SHA-256 是第二種支持的類型。因此,現在可以使用 SHA-256 創建 Git 倉庫(只需使用 --object-format=sha256 標誌),大多數本地操作都會正常工作。

然而,目前尚不存在 SHA-1 和 SHA-256 倉庫之間的相互操作性,並且 Git 托管提供商似乎都不支持 SHA-256。這種支持(或缺乏支持)很重要,因為無法推送到 Git 熔爐的倉庫對許多人來說將是無用的。此外,使用 SHA-256 的較長散列可能會破壞 Git 項目以外開發的工具,這種風險也無法完全消除。整體而言,這是一種尚未準備好用於現實世界的功能。

雖然如此,值得注意的是,迄今為止完成大部分散列轉換工作的 brian m. carlson 對 Bjarmason 的評估持不同看法。在他看來,目前唯一“可以辯解

的”使用 SHA-1 的原因是與 Git 熔爐提供商的相互操作性。否則,他認為 SHA-1 已經過時,並且使用 SHA-256 的性能可能“大幅提升”。但是,他同意所需的相互操作性目前尚不存在,且沒有人表示它即將在短期內到來。

因此,目前看來,Git 專案在支持 SHA-256 方面的工作似乎已經停止。至於什麼原因導致了這種情況,目前還不清楚。但是,這並不意味著 Git 將永遠不會支持 SHA-256 或其他散列算法。相反,可能是因為尚未解決所有技術問題,或者可能是因為其他原因(例如技術資源有限)。無論原因是什麼,重要的是要記住,Git 項目的開發人員一直在努力使其更強大、更安全,並且將繼續努力。

Mac 上用 Homebrew 安裝 Java 的方式

寫個自己看的,順便整理一些簡單的歷史。

一開始可以先看一下 java 跑起來如何:

$ java --version
The operation couldn't be completed. Unable to locate a Java Runtime.
Please visit http://www.java.com for information on installing Java.

順便一提,這邊的 java 可以用 which java 看到是出自 /usr/bin/java

然後透過 Homebrew,可以選擇不同的 JDK 套件安裝,在網路上常見的答案是 temurin (adoptopenjdk 的後繼者):

brew install temurin

這個好處是裝完可以直接用:

$ java --version
openjdk 19.0.1 2022-10-18
OpenJDK Runtime Environment Temurin-19.0.1+10 (build 19.0.1+10)
OpenJDK 64-Bit Server VM Temurin-19.0.1+10 (build 19.0.1+10, mixed mode)

另外一種是 OpenJDK,裝完後還得補個 symbolic link:

brew install openjdk
sudo ln -sfn /opt/homebrew/opt/openjdk/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk.jdk

可以看到這個版本的輸出不太一樣:

$ java --version
openjdk 19.0.1 2022-10-18
OpenJDK Runtime Environment Homebrew (build 19.0.1)
OpenJDK 64-Bit Server VM Homebrew (build 19.0.1, mixed mode, sharing)

然後不管哪種裝法都記得設定 JAVA_HOME

export JAVA_HOME="$(/usr/libexec/java_home)"

基本上就能動了。

Ruby 3.2.0 把 YJIT 列為穩定功能了

去年有寫過 RubyYJIT 帶來的效能提昇:「YJIT 帶給 Ruby 大量的效能提昇」。

在這次的 Ruby 3.2.0 發布就把 YJIT 列為穩定功能了:「Ruby 3.2.0」。

  • YJIT is no longer experimental
    • Has been tested on production workloads for over a year and proven to be quite stable.

另外就是支援的平台,看起來是多了 arm64 這邊的支援,所以馬上列表就多了一堆新機器:

  • YJIT now supports both x86-64 and arm64/aarch64 CPUs on Linux, MacOS, BSD and other UNIX platforms.
    • This release brings support for Apple M1/M2, AWS Graviton, Raspberry Pi 4 and more.

另外是每個程式語言幾乎都會遇到的 regexp 類的問題,這次 Ruby 3.2.0 利用 Memoization 的方式降低某些 regexp 的消耗:

# This match takes 10 sec. in Ruby 3.1, and 0.003 sec. in Ruby 3.2
/^a*b?a*$/ =~ "a" * 50000 + "x"

而另外一組 regexp 也可以看出類似的效果:

用一些記憶體空間換取效能,降低被 DoS 的一些機會。另外一方面,引入了 regexp timeout 的 workaround,緩解真的被打的時候的資源消耗上限:

The optimization above cannot be applied to some kind of regular expressions, such as those including advanced features (e.g., back-references or look-around), or with a huge fixed number of repetitions. As a fallback measure, a timeout feature for Regexp matches is also introduced.

LastPass 離職員工的爆料

這次 LastPass 出包搞的蠻大的,在官方的「Notice of Recent Security Incident」的裡面有提到這次的資料外洩包括了使用的 encrypted vault data 也被洩漏了:

The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.

官方一直強調這是 encrypted data,但離職員工爆料加密強度不足的問題:「1606428769731878913.html」,其中這段在講 legacy 版本的加密問題,居然曾經用過 ECB mode

Lots of vault entries may be encrypted with ECB mode AES-256. I worked on supporting unauthenticated CBC mode. But re-encrypting a users vault entries requires having their master key.

這個如同 Hacker News 上的討論「I worked at LastPass as an engineer (twitter.com/ejcx_)」提到的,以 1980 年代的標準就已經知道 ECB mode 的問題了:

> Lots of vault entries may be encrypted with ECB mode AES-256.
Wtf wtf wtf. This would be considered wildly insecure even by the standards of the 80s

其他提到 PBKDF2 的強度是逐步增加,從早期的 5000 到現在預設的 100100,這點倒是可以理解。

要避免依賴廠商的資安,一種方式是用目前成熟的開源 Password Manager,並且使用檔案儲存 (像是 KeePassXC 這類工具),再搭配 file sync 的工具跨機器使用 (像是 Syncthing 這樣獨立確認每個 device 身份的方式),但方便性不會像這些商用方案這麼好用就是了...

這次故事好像還沒結束,遇到西方的長假,反應都比較慢...

讓使用者可以自己選擇 Push notification service 的 UnifiedPush

前幾天 Hacker News Daily 上看到的,F-Droid 寫了一篇文章介紹可以讓使用者自己選擇 Push notification service 的 UnifiedPush:「UnifiedPush: A decentralized, open-source push notification protocol (f-droid.org)」。

一般在 Android 平台上是透過 Google 自家提供的 FCM 傳遞 push notification 訊息:

A modern Android smartphone relies on a lot of services, from app stores and calendars to messaging and push notifications. Most of them have open alternatives, but until now, the only option for push notifications was Google’s proprietary service, Firebase Cloud Messaging (FCM).

但這樣很明顯會遇到隱私問題 (i.e. Google 可以知道所有的 push notification),所以一直都有要怎麼解決的討論。

而看起來 UnifiedPush 給了一個方案:使用者在 Android 手機上安裝一隻程式 (ntfy),這隻程式可以連到使用者指定的伺服器接收 push notification (可以是自架或是用現有的服務),另外一方面,當然也會跟 app 說要把 push notification 送到哪邊。

另外也考慮到使用者如果極度在意電池的問題,還是可以 fallback 回去使用 Google 的 FCM,也就是不影響現有使用者的體驗。

這樣就可以做到還是單一連線 (降低電力使用),但是是分散式的架構,而且使用者有一定的控制權。

目前支援的 app 看起來不多,但可以以預期後續 F-Droid 上面的 app 應該會有不少 app 會支援:「Apps using UnifiedPush」。