Git 的 Diff 演算法

Lobsters Daily 上看到「When to Use Each of the Git Diff Algorithms」這篇 2020 的文章 (Lobsters 這邊常冒出一些舊文章),講 Git 的 diff 演算法。

文章裡面題到了四個演算法,看了一下 git-diff 的 manpage 也還是這四個:

--diff-algorithm={patience|minimal|histogram|myers}

另外看 manpage 時還有看到 --anchored 的用法,看起來是用來提示 Git 產生比較好懂的 diff 結果:

--anchored=<text>

Generate a diff using the "anchored diff" algorithm.

This option may be specified more than once.

If a line exists in both the source and destination, exists only once, and starts with this text, this algorithm attempts to prevent it from appearing as a deletion or addition in the output. It uses the "patience diff" algorithm internally.

回頭翻了一下自己的 config repository,看起來 2017 年年底的時候我就加了「Use histogram diff algorithm.」,然後過幾天換成「Use patience algorithm.」,就一直用到現在...

這次改用 minimal 跑一陣子看看好了...

XFCE 配上 Chromium 系列瀏覽器 (Chrome/Brave/...),視窗最大化時的問題

今天發現 Brave 在視窗最大化時會超出預期的邊界,而非放大到螢幕的邊緣,找了一下發現有人已經在 Brave 的 GitHub 上開了「Incorrect scale if browser is full screen #18964」這張票,後來看到有人說在 Chromium 的 bug system 上已經有人提出來了:「Issue 1257119: Goes under the taskbar when maximized」、「Issue 1260821: maximise gets screen dimension wron」與「Issue 1261797: [User Feedback - Stable] Reports that when Chrome is maximized after being minimized, it launches to beyond the window frame on Linux」。

這次遇到的 bug 看起來是只有用 XFCE 的使用者才會中獎,目前先摸索出一套 workaround 是透過 wmctrl 操作修改瀏覽器的位置與視窗大小。

方法是先用 wmctrl -l -G 列出所有視窗的資訊,包括 geometry 的資料,接著再用 wmctrl -i -r 0x12345678 -e 0,3760,15,1232,1935 這樣的指令去指定瀏覽器的位置與視窗大小。

不知道要撐多久就是了...

Linux Kernel 與明尼蘇達大學之間的攻防

Linux Kernel Community 與明尼蘇達大學 (UMN) 之間的事件差不多告一段落了,整理一下裡面比較重要的事件。隔壁棚 Basecamp 的事情還在燒,讓子彈多飛一點時間,等該跑出來的內部資訊都跑出來以後再來整理...

Linux Kernel 這件事情各家媒體都有整理出來,這邊拉 ZDNet 的文章來看:

講一下我的感想,因為 UMN 可以從這次事件證明了 Linux Kernel Community 沒有足夠的能力抵禦這類惡意攻擊,而且 Linux Kernel Community 也沒有打算解決這件事情,如果要比喻的話,很像台灣常看到的「解決發現問題的人」。

只要流程沒有改善,幾乎可以預測出之後會有政府資助的方式塞 buggy patch 進去埋洞。

作為 Linux 作業系統使用者,看起來沒什麼可以改變的,只能從架構面上設計出來安全界線,讓被攻進來時有一些防線防止直接打穿到底...

Google 釋出網頁版的 Spectre 攻擊 PoC,包括 Apple M1 在內

在大約三年前 (2018 年年初) 的時候,在讀完 Spectre 之後寫下了一些記錄:「讀書時間:Spectre 的攻擊方式」,結果在 Bruce Schneier 這邊看到消息,Google 前幾天把把 PoC 放出來了:「Exploiting Spectre Over the Internet」,在 Hacker News 上也有討論:「A Spectre proof-of-concept for a Spectre-proof web (googleblog.com)」。

首先是這個攻擊方法在目前的瀏覽器都還有用,而且包括 Apple M1 上都可以跑:

The demonstration website can leak data at a speed of 1kB/s when running on Chrome 88 on an Intel Skylake CPU. Note that the code will likely require minor modifications to apply to other CPUs or browser versions; however, in our tests the attack was successful on several other processors, including the Apple M1 ARM CPU, without any major changes.

即使目前的瀏覽器都已經把 performance.now() 改為 1ms 的精度,也還是可以達到 60 bytes/sec 的速度:

While experimenting, we also developed other PoCs with different properties. Some examples include:

  • A PoC which can leak 8kB/s of data at a cost of reduced stability using performance.now() as a timer with 5μs precision.
  • A PoC which leaks data at 60B/s using timers with a precision of 1ms or worse.

比較苦的消息是 Google 已經確認在軟體層沒辦法解乾淨,目前在瀏覽器上只能靠各種 isolation 降低風險,像是將不同站台跑在不同的 process 裡面:

In 2019, the team responsible for V8, Chrome’s JavaScript engine, published a blog post and whitepaper concluding that such attacks can’t be reliably mitigated at the software level. Instead, robust solutions to these issues require security boundaries in applications such as web browsers to be aligned with low-level primitives, for example process-based isolation.

Apple M1 也中這件事情讓人比較意外一點,看起來是當初開發的時候沒評估?目前傳言的 M1x 與 M2 不知道會怎樣...

GTA Online 釋出官方修正,大幅改善啟動效能

看到「GTA Online load time fix released, shaves off actual minutes of waiting for some」這邊的消息,先前在「GTA 的啟動讀取效能問題」這邊提到 GTA Online 啟動速度很慢的問題,官方正式推出修正版本了:「GTAV Title Update 1.53 Notes (PS4 / Xbox One / PC)」。

抓了一些在 Reddit 的討論「Loading Times Have FINALLY been patched - Discussion Thread」。

這則降的比率與當時 workaround 的修正差不多:

Insane. GTA menu -> GTA: Online.

Dropped from 7 minutes to 1:57

i7-2600k,GTX1070,16GB RAM and the game is on HDD.

這個就有點誇張了,這是 90% 吧?

Dropped from 5-8 minutes to 35 seconds

這個差不多 70%~80%:

Loading time 2m 20s for online directly from steam. Before it was like 8-10 minutes for me. Damn

Edit: 50s for story mode. 35s from story mode to online. So it seems it's still faster to load into online from story mode.

這個也差不多 70%:

From 4-5 minutes to 1 a minute and 22 seconds. Y e s p l e a s e

然後 PS4 的版本原來也受到一樣的影響?

Currently tested on PS4 , from main menu to online : 3min 45 sec From story mode to online: 1min 20sec (😩 i can't tell for sure )

整體看起來是正面的,畢竟大家等這個問題等超久了... 另外也可以看出來當初的 workaround patch 其實相當精準的把問題都解掉了,官方的修正並沒有快更多。

來繼續關注 libc 那邊的問題...

sscanf() 與 strlen() 的故事繼續發展

昨天在「GTA 的啟動讀取效能問題」這邊提到了 sscanf()strlen() 的問題,剛剛在 Hacker News Daily 上又看到一篇「It Can Happen to You」,在講他自己的專案也中獎。

他提到了一個解法,用 strtof() 取代 sscanf() 讀數字,結果大幅降低了 parsing 的時間:

Replacing the sscanf call with strtof improved startup by nearly a factor of 10: from 1.8 seconds to 199 milliseconds.

文章的最後面題到了不少目前正在進行中的討論與 patch。

首先是 FreeBSD 上的 patch 已經在測試:「address a performance problem w/ partial sscanf on long strings...」,裡面可以看到有很小心的在研究會不會造成 performance regression。

然後是 glibc 這邊,在 2014 年就有被開了一張票提出來:「Bug 17577 - sscanf extremely slow on large strings」,不過下面只是多了幾個 comment,目前沒有任何進度。

然後是 cppreference.com 上的「std::scanf, std::fscanf, std::sscanf」頁面則是加注了複雜度的問題:

Complexity

Not guaranteed. Notably, some implementations of sscanf are O(N), where N = std::strlen(buffer) [1]. For performant string parsing, see std::from_chars.

感覺接下來應該還會有更多人提出自己的災情,或是有人發現某個跑很慢的專案也是因為這個原因...

Python 2 的後續支援

雖然 2020/01/01 開始 Python 2 就沒有官方支援了 (翻了一下資料發現「Python 2 series to be retired by April 2020」這篇,官方好像延到四月了...),不過剛剛看到這則新聞,裡面提到了商業支援:「Snakes on a wane: Python 2 development is finally frozen in time, version 3 slithers on」。

在最後一段:

Those catering to corporate clients intend to continue support Python 2.7 for a while. In October, Red Hat said it will stop supporting Python 2.7 in RHEL 8 come June 2024.

不確定這些 patch 會不會也移植到 CentOS 上,如果會的話,至少有一個地方可以讓你多四年掙扎,感覺上可以用 container 生一個獨立的環境...

另外 Ubuntu 這邊的 LTS 不知道有什麼方案,已知 20.04 的目標是要移除掉,但 16.04 與 18.04 裡的 Python 2 如果有問題時,不知道會不會收 patch...

再來就是 pyenv 了,翻了一下目前的情況,好像就是放著,不知道會有什麼方案搬出來...

在一連串的安全更新後,AMD 的 CPU 比 Intel 快了...

在「Intel Performance Hit 5x Harder Than AMD After Spectre, Meltdown Patches」這邊看到的測試:

把現有的安全性更新都開啟後,Intel CPU 的效能掉了 20% 左右 (在 Intel 上需要把 HT 關掉):

While the impacts vary tremendously from virtually nothing too significant on an application-by-application level, the collective whack is ~15-16 percent on all Intel CPUs without Hyper-Threading disabled. Disabling increases the overall performance impact to 20 percent (for the 7980XE), 24.8 percent (8700K) and 20.5 percent (6800K).

The AMD CPUs are not tested with HT disabled, because disabling SMT isn’t a required fix for the situation on AMD chips, but the cumulative impact of the decline is much smaller. AMD loses ~3 percent with all fixes enabled

可以注意到兩家目前桌機的頂規在上了安全性更新後,AMD 的 2990WX 比 Intel 的 7980XE 快了一些些... 當初擠牙膏擠出來的都吐回去了,不知道之後出的 security issue 還需要再吐多少回去。

Linux Kernel 4.20 修正了一卡車 Intel CPU bug,然後效能掉光了...

看到「Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower」這篇測試了目前還在 RC 的 4.20.0,可以看到 AMD 的效能沒有太大影響,但 Intel i9 的效能掉了很嚴重:

從說明可以看到有測出 30%~50%:

This ranged from Rodinia scientific OpenMP tests taking 30% longer to Java-based DaCapo tests taking up to ~50% more time to complete to code compilation tests taking measurably longer to lower PostgreSQL database server performance to longer Blender3D rendering times.

另外在其他 Intel CPU 上測試也發現不是只有 i9 有影響,低階的機器也是:

Those affected systems weren't high-end HEDT boxes but included a low-end Core i3 7100 as well as a Xeon E5 v3 and Core i7 systems.

透過 bisect 有找到是哪個 commit 造成的:

That change is "STIBP" for cross-hyperthread Spectre mitigation on Intel processors. STIBP is the Single Thread Indirect Branch Predictors (STIBP) allows for preventing cross-hyperthread control of decisions that are made by indirect branch predictors.

但這又是屬於 security patch,不太能關... 加上自從 MeltdownSpectre 後,讓安全研究人員發現了全新的天地,之後應該只會愈來愈慘 :o

Ubuntu 推出 14.04 的 ESM 計畫

Ubuntu 14.04LTS 版本,在明年四月底 (也就是 2019 年四月) 將會滿五年的維護期,之後就不會有任何公開更新了 (包括安全性更新)。

在前一次的 Ubuntu 12.04 是第一次提供 ESM (Extended Security Maintenance) 服務,讓沒辦法即時轉及到新版的單位可以付費繼續收到安全性更新,算是 LTS 的一個重要服務。

而官方這次也對 Ubuntu 14.04 推出了 ESM:「Announcing Extended Security Maintenance for Ubuntu 14.04 LTS – “Trusty Tahr”」。

Ubuntu 14.04 LTS – ESM will become available once Ubuntu 14.04 reaches its End of Life on April 30, 2019.

價錢應該會跟之前類似吧...