Tag: number

自己小修一下 fcitx5-mcbopomofo 的選詞數量

之前有提過「Linux 上 fcitx5 的小麥輸入法」，在我自己桌面都換成 Ubuntu 22.04 後都能裝了，就用了一陣子。

但選字的數量一直覺得怪怪的，本來的數量是九個，像是這樣：

看了一下 Windows 上的新酷音，介面上因為設計成 3x3 的關係，所以看起來就不會不舒服：

所以就在想，如果是一行的為什麼不是十個？翻了翻程式碼，看起來在 src/McBopomofo.cpp 這邊：

  if (keysConfig == SelectionKeys::Key_asdfghjkl) {
    selectionKeys_.emplace_back(FcitxKey_a);
    selectionKeys_.emplace_back(FcitxKey_s);
    selectionKeys_.emplace_back(FcitxKey_d);
    selectionKeys_.emplace_back(FcitxKey_f);
    selectionKeys_.emplace_back(FcitxKey_g);
    selectionKeys_.emplace_back(FcitxKey_h);
    selectionKeys_.emplace_back(FcitxKey_j);
    selectionKeys_.emplace_back(FcitxKey_k);
    selectionKeys_.emplace_back(FcitxKey_l);
  } else if (keysConfig == SelectionKeys::Key_asdfzxcvb) {
    selectionKeys_.emplace_back(FcitxKey_a);
    selectionKeys_.emplace_back(FcitxKey_s);
    selectionKeys_.emplace_back(FcitxKey_d);
    selectionKeys_.emplace_back(FcitxKey_f);
    selectionKeys_.emplace_back(FcitxKey_z);
    selectionKeys_.emplace_back(FcitxKey_x);
    selectionKeys_.emplace_back(FcitxKey_c);
    selectionKeys_.emplace_back(FcitxKey_v);
    selectionKeys_.emplace_back(FcitxKey_b);
  } else {
    selectionKeys_.emplace_back(FcitxKey_1);
    selectionKeys_.emplace_back(FcitxKey_2);
    selectionKeys_.emplace_back(FcitxKey_3);
    selectionKeys_.emplace_back(FcitxKey_4);
    selectionKeys_.emplace_back(FcitxKey_5);
    selectionKeys_.emplace_back(FcitxKey_6);
    selectionKeys_.emplace_back(FcitxKey_7);
    selectionKeys_.emplace_back(FcitxKey_8);
    selectionKeys_.emplace_back(FcitxKey_9);
  }

看起來是為了跟 asdfghjkl 九個鍵對齊設計的，但這樣覺得不舒服... 所以在 selectionKeys_.emplace_back(FcitxKey_9); 後面加上 selectionKeys_.emplace_back(FcitxKey_0);，再重新編 + 裝 + 重啟後再輸入就變成十個了：

這樣自己用是沒問題，但暫時想不到怎麼找出一個好方法併回去... 也許多一組 SelectionKeys::Key_1234567890？

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)：

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

Linux 打算合併 /dev/random 與 /dev/urandom 遇到的問題

在 Hacker News 上看到「Problems emerge for a unified /dev/*random (lwn.net)」的，原文是「Problems emerge for a unified /dev/*random」(付費內容，但是可以透過 Hacker News 上的連結直接看)。

標題提到的兩個 device 的性質會需要一些背景知識，可以參考維基百科上面「/dev/random」這篇的說明，兩個都是 CSPRNG，主要的分別在於 /dev/urandom 通常不會 block：

The /dev/urandom device typically was never a blocking device, even if the pseudorandom number generator seed was not fully initialized with entropy since boot.

而 /dev/random 不保證不會 block，有可能會因為 entropy 不夠而卡住：

/dev/random typically blocked if there was less entropy available than requested; more recently (see below, different OS's differ) it usually blocks at startup until sufficient entropy has been gathered, then unblocks permanently.

然後順便講一下，因為這是 crypto 相關的設計修改，加上是 kernel level 的界面，安全性以及相容性都會是很在意的點，而 Hacker News 上的討論裡面很多是不太在意這些的，你會看到很多「很有趣」的想法在上面討論 XDDD

回到原來的文章，Jason A. Donenfeld (Linux kernel 裡 RNG maintainer 之一，不過近期比較知名的事情還是 WireGuard 的發明人) 最近不斷的在改善 Linux kernel 裡面這塊架構，這次打算直接拿 /dev/random 換掉 /dev/urandom：「Uniting the Linux random-number devices」。

不過換完後 Google 的 Guenter Roeck 就在抱怨在 QEMU 環境裡面炸掉了：

This patch (or a later version of it) made it into mainline and causes a large number of qemu boot test failures for various architectures (arm, m68k, microblaze, sparc32, xtensa are the ones I observed). Common denominator is that boot hangs at "Saving random seed:". A sample bisect log is attached. Reverting this patch fixes the problem.

他透過 git bisect 找到發生問題的 commit，另外從卡住的訊息也可以大概猜到在虛擬機下 entropy 不太夠。

另外從他們三個 (加上 Linus) 在 mailing list 上面討論的訊息可以看到不少交流：「Re: [PATCH v1] random: block in /dev/urandom」，包括嘗試「餵」entropy 進 /dev/urandom 的 code...

後續看起來還會有一些嘗試，但短期內看起來應該還是會先分開...

Linux Kernel 裡的 RNG 從 SHA-1 換成 BLAKE2s

從 Hacker News Daily 上看到的消息，Linux Kernel 裡的 RNG，裡面用到的 SHA-1 演算法換成 BLAKE2s 了：

SHA-1 已知的問題是個隱患，不過換成 BLAKE2s 應該是 maintainer 的偏好，Jason Donenfeld 在 WireGuard 裡面也是用 BLAKE2s...

把 YouTube 的 Dislike 數字弄回來

最近 YouTube 也在搞事，把 Dislike 的數字拔掉了，後來在 Greasy Fork 上面找了一下，看到有兩套方法可以把數字補回來。

第一套是「Return YouTube Dislike」這個方法，從程式碼裡面可以看到是透過 API 拉出來的：

function setState() {
  cLog('Fetching votes...');
 
  doXHR({
    method: "GET",
    responseType: "json",
    url:
      "https://return-youtube-dislike-api.azurewebsites.net/votes?videoId=" +
      getVideoId(),
    onload: function (xhr) {
      if (xhr != undefined) {
        const { dislikes, likes } = xhr.response;
        cLog(`Received count: ${dislikes}`);
        setDislikes(numberFormat(dislikes));
        createRateBar(likes, dislikes);
      }
    },
  });
}

這個 API 後面應該是接 Videos: getRating 拉資料出來，但畢竟不是直接打 YouTube API (比較麻煩，需要每個使用者自己申請 API token)，這樣就有隱私的疑慮了...

另外一套是「Show Youtube Dislike Count」，看了裡面程式碼發現他是用 averageRating 反推回來：

if (likeCount >= 0) {
    const r = data.playerResponse.videoDetails.averageRating;
    const dislikeCount = Math.round(likeCount * (5 - r) / (r - 1));

    ShowDislikes(likeCount, dislikeCount);
}

不過作者有點偷懶，這邊在等待頁面生成單純用 100ms 等頁面出現，有時候還是會有 race condition (就是後面還是讀不到 XDDD)，如果懶的大修的話可以改成 1000ms 混過去，降低一些機率：

while (!isLoaded) {
    await Sleep(100);
}

另外數字很大的時候會稍微不準，但也算夠用了，先暫時用這套來頂著了...

Kaspersky Password Manager 的漏洞

在 Hacker News Daily 上看到「Kaspersky Password Manager: All your passwords are belong to us」這篇，講 Kaspersky Password Manager (KPM) 嚴重的安全漏洞，另外在 Hacker News 上的討論「Kaspersky Password Manager: All your passwords are belong to us (ledger.com)」也有提到一些有趣的東西。

標題的 All your passwords are belong to us 是出自「All your base are belong to us」這個梗的變形。

這包安全問題主要的原因是因為 KPM 沒有使用 CSPRNG，而且也沒有正確 seed，所以極為容易被猜出密碼本身。

KPM 的 Web 版使用了 Math.random()，在各家瀏覽器主要是用 xorshift128+ 實做 Math.random()，作者沒有針對這塊再花時間研究，但很明顯的 Math.random() 不是個 CSPRNG：

The underlying PRNG used by Chrome, Firefox and Safari for Math.random() is xorshift128+. It is very fast, but not suitable to generate cryptographic material. The security consequences in KPM has not been studied, but we advised Kaspersky to replace it with window.crypto.getRandomValues(), as recommended by the Mozilla documentation page previously mentioned.

Note: Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely the window.crypto.getRandomValues() method.

而桌機版則是用了 MT19937，理論上取得 624 bytes 的輸出後就可以重建整個 PRNG 的內部狀態 (於是就可以預測後續的 output)，但這代表你要知道其他網站的密碼，這點其實有點困難。

但作者發現 KPM 在產生 MT19937 的 seed 只跟時間有關，超級容易被預測：

So the seed used to generate every password is the current system time, in seconds. It means every instance of Kaspersky Password Manager in the world will generate the exact same password at a given second.

於是可以直接暴力解出所有的可能性：

The consequences are obviously bad: every password could be bruteforced. For example, there are 315619200 seconds between 2010 and 2021, so KPM could generate at most 315619200 passwords for a given charset. Bruteforcing them takes a few minutes.

Hacker News 上有不少陰謀論的討論，像是：

Getting some DUAL_EC prng vibes.

Insert Kaspersky owned by Russia intelligence conspiracy here...

另外 Kaspersky 跟俄羅斯軍方的關係也是很知名，這些東西大概要到十來年後才會知道...

Facebook 5.33 億筆個資外洩，以及 Mark Zuckerberg 的電話...

這兩天應該已經有很多其他媒體報導了 Facebook 5.33 億筆資料外洩的事情：「533 million Facebook users' phone numbers and personal data have been leaked online」。

據稱是用 2019 年的洞撈出來的，不過這份資料看起來也不是完整資料，舉個例子來說，台灣只有 73 萬筆左右，而且也少了很多地區，像是泰國就不在列表內...

另外一個比較特別的是，Mark Zuckerberg 的電話也在這次外洩資料裡面：「Mark Zuckerberg's phone number appeared among the leaked data of Facebook users, according to a researcher」，應該會換號碼了。

這包資料看起來會這陣子會很熱門...

YAML 的問題 (挪威問題)

Hacker News 首頁上看到的，YAML 寫多的人都遇過類似的問題：「The Norway Problem - why StrictYAML refuses to do implicit typing and so should you」，對應的討論「The Norway Problem (hitchdev.com)」也可以看一下。

第一個「經典」是字串不需要包起來就很容易出事，這邊提到的例子是因為保留字而中槍，挪威的簡碼 NO 變成 False 了：

countries:
- GB
- IE
- FR
- DE
- NO
>>> from pyyaml import load
>>> load(the_configuration)
{'countries': ['GB', 'IE', 'FR', 'DE', False]}

同樣的是字串問題，「看起來」是數字的就會變成數字：

python: 3.5.3
postgres: 9.3

然後還是字串，人名遇到保留字：

first name: Christopher
surname: Null

這種問題都是碰過一次學一次...

作者另外提到的 StrictYAML 改變了 YAML 規格，我會看看就好，能用 JSON 也許還是會偏好先用 JSON，不是完全解決，但踩雷的機率會少很多。

產生名次的 SQL

在 Percona 的「Generating Numeric Sequences in MySQL」這篇在討論產生字串序列，主要是在 MySQL 環境下，裡面看到的技巧「Session Variable Increment Within a SELECT」這組，剛好可以用在要在每個 row 裡面增加名次：

SELECT (@val := @val + 1) - 1 AS value FROM t1, (SELECT @val := 0) AS tt;

另外看到 MariaDB 與 MySQL 8.0 系列因為有多支援各種功能，剛好也可以被拿來用，然後最後也提到了 Percona 自家出的 MySQL 8.0.20-11 將會直接有 SEQUENCE_TABLE() 可以用 (這應該才是 Percona 這篇文章的主要目的，推銷一下自家產品的新功能)。

文章收起來之後遇到可以拿出來參考用...

改變 Xfce Terminal 的 Alt-Number 快速鍵功能

前陣子桌機重裝 Ubuntu，順便把桌面環境換成 Xubuntu 用看看，也把本來再用的 GNOME Terminal 換成 Xfce 的 Terminal。

我的習慣會把 GNOME Terminal 的 Alt-Number (像是 Alt-1) 快速鍵改掉，因為有不少程式會吃這組快速鍵，像是 tmux 切換視窗內玻璃 (pane) 排列的 preset 以及 IRC client 在不同頻道的切換。

但 Xfce Terminal 沒有 GUI 讓你改這組快速鍵 (其他的快速鍵有，但也雷雷的，後面會提到...)，翻了翻看起來只有「Disable alt-n tab shortcut in xfce-terminal?」這邊有提到，算是堪用：

~/.config/xfce4/terminal/accels.scm looked promising but my changes were undone after a restart, so I made it read-only but it turns out commenting out the relevant lines makes no difference anyway.

雖然作者有提到它改了 ~/.config/xfce4/terminal/accels.scm 沒用，我自己發現這邊的確是很 buggy，但暫時還是可以找到 workaround。

解法是直接改沒錯，但不能直接註解掉，而需要改空，也就是本來的：

(gtk_accel_path "<Actions>/terminal-window/goto-tab-1" "<Alt>-1")

不能改成：

; (gtk_accel_path "<Actions>/terminal-window/goto-tab-1" "<Alt>-1")

而是要改空：

(gtk_accel_path "<Actions>/terminal-window/goto-tab-1" "")

另外要注意，透過 GUI 修改快速鍵後，~/.config/xfce4/terminal/accels.scm 裡面的內容也會被重製，也就是 Xfce Terminal 寫入這個檔案時是直接把預設值寫進去，而非把有效值寫進去：

這點算是比較地雷的地方...