はてなブログで mermaid を使う (2023/3/7追記あり)

天文ブログの方でフローチャート風の図を描くのに Mermaid を使ってみたのだけど、うまくいかないことがあったので回避方法をメモ。

Mermaid はダイアグラムやチャートを Markdown 風の記法で記述して、JavaScript で図として描画する仕組みで、数式における MathJax に相当するもの。

はてなブログの場合、数式に関しては「はてな記法」で書けば事足りるのだが、Marmaid については識別用のタグを付けたブロックに marmaid の記法で記述して、その後ろに JavaScript のコード断片をコピペしておくことで、閲覧者のブラウザ上で JavaScript を動かしてブロックを図(SVG)に変換するというやり方になる。たとえば以下のように(ブログをはてな記法で書く場合)。

><pre class="mermaid">
graph TD
    Hello --> World
</pre><script type="module">import mermaid from 'https://unpkg.com/mermaid@9/dist/mermaid.esm.min.mjs';mermaid.initialize({ startOnLoad: true });</script><

これは以下のように表示される。

graph TD
    Hello --> World

はてなブログはデフォルトで編集画面で入力した論理行を p タグで囲んで表示してしまうため、mermaid をそのまま書くとエラーになってしまうので ><pre class="mermaid">...</script>< のように「pタグ停止記法」を使用している。*1

しかし、これでうまくいかない場合がある。たとえば以下。

><pre class="mermaid">
graph TD
    iPhone --> Xperia
</pre><script type="module">import mermaid from 'https://unpkg.com/mermaid@9/dist/mermaid.esm.min.mjs';mermaid.initialize({ startOnLoad: true });</script><

ラベル名が変わっただけなのだが、これは描画に失敗してしまう。

graph TD
    iPhone --> Xperia

これはブログのHTMLに変換される際に「iPhone」「Xperia」といった単語に「はてなキーワード」のマークアップが追加されてしまうからだ。上の例だと pre タグのブロックは以下のように変換されてしまう。

<pre class="mermaid">graph TD
    <a class="keyword" href="http://d.hatena.ne.jp/keyword/iPhone">iPhone</a> --&gt; <a class="keyword" href="http://d.hatena.ne.jp/keyword/Xperia">Xperia</a>
</pre>

「pタグ停止記法」はあくまで p タグの挿入を停止するだけで、他のタグは挿入されてしまう。「スーパーpre記法」と同等のブロック内に一切タグが挿入されない記法があればよいのだが…

そこでスーパーpre記法の中に mermaid を書きたいのだが、mermaid のスクリプトは class="mermaid" の付いた div または pre の直下のテキストしか見てくれないようで、スーパーpre記法をpタグ停止記法の ><pre class="mermaid">...</pre>< で囲んでもダメだった。

そこで以下のようにスクリプトを追加することで解決した。

><pre class="mermaid">
graph TD
    iPhone --> Xperia
</pre><script>document.querySelectorAll('.mermaid:not([processed])').forEach((e) => { e.innerHTML = e.textContent; e.setAttribute('processed', 'true'); }) </script><script type="module">import mermaid from 'https://unpkg.com/mermaid@9/dist/mermaid.esm.min.mjs';mermaid.initialize({ startOnLoad: true });</script><
graph TD
    iPhone --> Xperia

追加のスクリプトでは mermaid クラスの pre タグの内容をタグなしのテキストで置換する。また、このスクリプトがページ内に複数ある場合に処理が繰り返されないように*2 processed 属性を追加して、この属性があるタグは置換の対象にしないようにしてある。

スクリプトはロードされた時点で実行されるため、スクリプトが書かれた場所より手前にある pre タグしか置換されない。そのため mermaid クラスの pre タグの直後、mermaid のスクリプトより手前に書くようにする。

追記(2023-03-07): mermaid 記法(未満)、ありました…

なんと公式に mermaid 記法(未満)ありました。いつからあったんだろう?

スーパーPREの言語指定の部分に「mermaid」を指定しするだけ!と、言いたいところですが、mermaid の JavaScript は別途ロードしなくてはなりません。そこが「(未満)」と書いた所以です。

*1:script タグを「pタグ停止記法」の中に含めて </pre> に改行なしで続けて記述しているのは、はてなブログの記事一覧で並べて表示される記事の冒頭部分に mermaid がある時に図が正しく描画されることを期待してだが、確実な効果があるかは不明。

*2:置換が繰り返されても同じ内容になるので表示は変わらないが処理が無駄になる

うなぎ絶滅キャンペーンへのご協力ありがとうございます!

うなぎ絶滅キャンペーンへのご協力ありがとうございます!

うなぎは邪悪な生き物です!地球上に存在してよい種ではありません!旧約聖書にもそう書いてある。皆で食べて絶滅させましょう!

ご存知のように日本におけるうなぎの漁獲量は現象の一途をたどり、1970年代の3000トンが2019年には過去最低の3.7トンにまで減少しています!皆様のご協力に感謝します。あともう一息です!

でも、貧乏で養殖のうなぎしか食べれないし… というあなた!大丈夫です!養殖のうなぎを食べるだけでもうなぎ絶滅に貢献できます!

養殖のうなぎも元は天然の稚魚(シラスウナギ)を捕獲して育てたものだからです。卵から成魚まで育てる完全養殖が実用化されていない現在、養殖のうなぎを食べることは確実にうなぎ絶滅へと繋がる一歩となります!胸を張って食べていきましょう!

国際自然保護連合(IUCN)の「絶滅の恐れのある野生生物のリスト(レッド・リスト)」にはニホンウナギが「絶滅危惧種(EN)」として記載されていますが、水産庁ではニホンウナギの資源水準は「調査中」管理目標は「検討中」としています。

養殖や稚魚の捕獲についての管理措置はありますが、稚魚の密漁は絶えず、海外で捕獲された稚魚の密輸は野放し状態です。水産庁にも我々のキャンペーンへの賛同者が浸透しているのです!同志によるサボタージュが功を奏しているうちに皆でうなぎを食べ尽くし絶滅させましょう!

https://rna.sakura.ne.jp/share/diary/『寄生獣(2)』 この「種」を食い殺せ.jpg
岩明均寄生獣(2)』より

(初出:facebook)

解説

facebook でうなぎの蒲焼の写真をでかでかと載せて飯テロしてる人がいたので書きました。

Emacs の表示欠けの件

先日の、新メインPC/Ubuntu 20.04 への移行の際の未解決問題の一つの「Emacs の表示欠け」問題ですが…

あらためて再現動画を貼りますが、こんなんです。

あれから調べていたのですが、以下のことがわかりました。

  • 表示欠け状態は redraw-display または redraw-frame で修復できる。redisplay ではダメ。
  • emacs -q の初期設定で表示された *GNU Emacs* バッファでも再現する。
    • なのでフォント設定とか関係なさそう。
    • 表示欠けの部分が真っ白ではなくGNUアイコンの一部が描かれる場合がある。
  • ASCII 文字だけのバッファでも発生。
    • 日本語表示が原因というわけではなさそう。
  • scroll-down, scroll-down-command, recenter-top-bottom によるスクロールで再現するが常に再現するわけではない。
  • 表示欠けはウィンドウの最下行かその近くの行で発生する。

というわけで、ウインドウがスクロールするタイミングで redraw-frame を呼び出せばいいのでは?と思って以下のような設定をしてみました。

;; スクロール時に表示が欠けるバグの回避
(defun my-auto-redraw (win start)
  (redraw-frame))

(defun my-auto-redraw-setup ()
  (if (not (member 'my-auto-redraw window-scroll-functions))
      (progn
       (add-hook 'window-scroll-functions 'my-auto-redraw nil t))))

(add-hook 'after-change-major-mode-hook 'my-auto-redraw-setup)

スクロール発生時に呼び出される hook は window-scroll-functions ですが、buffer 毎に add-hook してあげないとダメみたいで、じゃあ buffer が作られる時に呼ばれる hook は?と思ったら、どうもないみたいなんですね…

代替案として after-change-major-mode-hook と buffer-list-update-hook が候補に上がっているのですが、buffer-list-update-hook が呼び出された時の current buffer がどれになるかよくわからなくて after-change-major-mode-hook でやりました。

これでうまくいくかと思ったら、表示欠けの発生自体は防げませんでした… でも C-l なり C-v なりでスクロールしたタイミングで修復されるので、ウィンドウの下の方で編集を続けるのでない限りは気にならなくなりました。表示が重くなったりちらついたりしないかと思ったのですが、GPUが速いせいか全然気にならないレベルでした。

とりあえずこれで様子見ですかね。バグレポとかした方がいいのかなぁ。でも検索しても他に発生してる報告を見かけないので環境特有の何かっぽいんですよね。うーむ…

メインPC新調 (ソフトウェア編)

前回の続きです。


Ubuntu 20.04 インストール

旧PCの Ubuntu 18.04 上で Ubuntu 20.04.1 ja (日本語Remix) をダウンロードしてブータブルUSBメモリを作成。

組み立てOSが何も入ってない状態で USB メモリを挿して起動したら普通にインストーラが起動しました。Ryzen PRO 4000 シリーズ(Renoir) の内蔵GPUが 20.04 の初期状態で動かないことがあるという話を聞いていましたが、HDMI で Full-HD モニターを繋いだ限りは大丈夫でした。*1

インストール先の SSDパーティションをいつものように切っていたら、インストールに進もうとすると、EFIシステムパーティションが必要だよ、このままだとブートしなくなるよ、みたいな警告が出て、EFIシステムパーティションて何?ってなったので調べました。

OSのブートローダーを入れる用のパーティションのようですね。MBRが手狭になったからこんなのできたんですかね?128MBもあれば十分みたいなので、それで設定しました。念の為 HDD の方にも作っておきました。なんかあった時にブートドライブにするかもしれないので。SSD は残り全部 / に、HDD は残り全部 /home に、swap パーションはナシ、で行きました。

その先は特にトラブルなくデスクトップが立ち上がりました。デスクトップは標準の Xorg を使いました。Wayland はまだ安定性が心配なのと、旧メインPCでベンチマークを測定しても特に速いわけではなかった(むしろ Xorg よりちょっと遅い)ので今回はパスしました。

デスクトップは今まで GNOME Flashback を使っていたのですが、home には Ubuntu 10.04 あたりからずっと引き継いできた秘伝のタレみたいな設定が仕込まれていて、トラブルの際に何がどうなってるのかよくわからなくなってきて放置になってる件もいくつかあり、この際一度まっさらな状態からやり直したいということもあって、今回から標準のデスクトップ環境を使うことにしました。標準のデスクトップならトラブルの際に情報も集めやすいというのもあって。

センサー関係

まずはハードウェアのトラブルをいち早くキャッチできるように、CPUやSSD/HDDの温度を確認できる体制にしたいと、hddtemp と lm-sensors をインストール。

$ sudo apt install hddtemp
$ sudo apt install lm-sensors
$ sensors-detect
...

sensors-detect は適当にやったのでよくおぼえていません… 基本デフォルトだったと思います。

この後 sensors-applet をインストールしたのですが、起動の仕方がわからず使用を断念。gnome-panel じゃないと使えない?

Ubuntu Software から適当に見繕った Hardware Sensors Indicator というのをインストールしました。パッケージ名は indicator-sensors です。

Preference で読み取るセンサーを選びます。CPU 温度は k10temp-pci-xxxx の Tdie、GPU 温度はたぶん amdgpu-pci-xxxx の edge、NVMe SSD の温度は nvme-pci-xxxx の Composite を見ればよいようです。HDD は HDD の型番が出てくるのでそれを。

これで温度が簡単に監視できるようになったのですが、トラブルが。indicator-sensors を起動したまま画面ロックまたは他のユーザーのデスクトップに切り替えてから戻ってくると、デスクトップがグレーアウトして、

Authentication is required to check power state for WDC WD40EFZX-...

という認証画面が表示されてデスクトップが一切操作できなくなってしまう現象が発生しました。キャンセルしても速攻再表示されます。認証すれば閉じると思ったのですが、一度は成功したものの、その後何度やっても認証が通らなくなって諦めて Ctrl+Alt+F3 でコンソール画面に入って X 関係のプロセスを kill するはめになりました…

どうやら以下の issue と同じ現象のようですが、まだ解決していないようです。

とりあえず HDD の温度表示は諦めて、Preference の Plugins タブから udisks2 を無効化しました。エラーメッセージでググるpolkit の設定ファイルを書き換えることで回避できるようなのですが、意味がよくわからないので敬遠しました。ていうか hddtemp 使ってないんですね。hddtemp を使うプラグインがあればいいのに…

ECC メモリは認識されている?

以下のコマンドでメモリが ECC かどうか確認できます。

$ sudo dmidecode -t 17
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.
# SMBIOS implementations newer than version 3.2.0 are not
# fully supported by this version of dmidecode.

Handle 0x0016, DMI type 17, 84 bytes
Memory Device
	Array Handle: 0x000F
	Error Information Handle: 0x0015
	Total Width: 72 bits
	Data Width: 64 bits
	Size: 16384 MB
	Form Factor: DIMM
...

ECC メモリでは Data Width と Total Width が同じ(64 bits)になるそうです。

エラー検出用のドライバは EDAC (Error Detection and Correction) というのですが、dmesg で EDAC がロードされて ECC が有効化されているのが確認できます。

$ dmesg
[    0.000000] Linux version 5.8.0-59-generic (buildd@lcy01-amd64-022) (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC 2021 (Ubuntu 5.8.0-59.66~20.04.1-generic 5.8.18)
...
[    4.140391] EDAC amd64: F17h_M60h detected (node 0).
[    4.140441] EDAC amd64: Node 0: DRAM ECC enabled.
[    4.140442] EDAC amd64: MCT channel count: 2
[    4.140517] EDAC MC0: Giving out device to module amd64_edac controller F17h_M60h: DEV 0000:00:18.3 (INTERRUPT)
[    4.140520] EDAC MC: UMC0 chip selects:
[    4.140522] EDAC amd64: MC: 0: 16384MB 1:     0MB
[    4.140524] EDAC amd64: MC: 2:     0MB 3:     0MB
[    4.140527] EDAC MC: UMC1 chip selects:
[    4.140528] EDAC amd64: MC: 0: 16384MB 1:     0MB
[    4.140529] EDAC amd64: MC: 2:     0MB 3:     0MB
[    4.140530] EDAC amd64: using x8 syndromes.
[    4.140545] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.0 (POLLED)
[    4.140546] AMD64 EDAC driver v3.5.0
...

メモリのエラー発生と訂正の情報は、edac-util で確認できます。

$ sudo apt install edac-utils
$ edac-util -sv
edac-util: EDAC drivers are loaded. 1 MC detected:
  mc0:F17h_M60h
$ edac-util -v
mc0: 0 Uncorrected Errors with no DIMM info
mc0: 0 Corrected Errors with no DIMM info
edac-util: No errors to report.

というわけで ECC は OS 側から認識されているようです。エラー発生・訂正の様子を実際に確認するにはメモリを起動でコケない程度にオーバークロックするとよいそうですが、さすがにそこまではやりませんでした…

データコピー

デスクトップ環境をまっさらな状態から構築する関係で旧PCの home ディレクトリをそのまま移行はしないのですが、データの大半は必要ですし、必要になるたびコピーするのは面倒なので、旧 home をまるごと新PCの適当なフォルダにコピーしました。2TB近くあるので、万一のデータ化けを防ぐために転送方法を工夫しました。

最初は samba をインストールして SMB 署名を有効(smb.conf の [global] セクションで server signing = mandatory を設定)にして nautilus からコピーしようとしたのですが、SMB だとシンボリックリンクのコピーでエラーになり、ずっと確認ダイアログが出てきて前に進まないので*2 ssh と tar を使いました。

まず新PC側に ssh サーバーをインストールします。

$ sudo apt install openssh-server

そして新PC側にコピー先になる一時ディレクトリを作成して(~/tmp とします)、旧PC側で以下のようにして home ディレクトリを丸ごと転送しました(ユーザー名 hoge は適当に置き換えてください)。

cd /home
tar cfpv - -C . hoge | ssh hoge@keynes.local 'tar xf - -C tmp'

tar の p オプションでシンボリックリンクシンボリックリンクのまま転送しています。

ssh を使ったのは暗号化された通信なら通信路でデータ化けが発生すれば送信先で復号できなくなってエラーになることが期待できるからです。エラーにならずに送信が完了すればデータは無事というわけです。

単純なコピーなら scp の方が簡単ですが、scp はシンボリックリンクはリンク先の実体をコピーする形でしかコピーできないので上の方法にしました。

キーボード、日本語入力

mozc の修正

今まで何度か書いてますが、US配列キーボード + かな入力 + NeXT かな配列 という少数派(ていうか他にそんな人いるのかな?)の日本語入力方式を使っている関係で、mozc に自作パッチを当てて使っています。fcitx-mozc, ibus-mozc, emacs-mozc に対応したパッチがこれです。

実際には古いパッチがそのままでは使えなかったので、このパッチは手修正したものから再作成したものです。

作業手順は、まず、apt のソースリポジトリを有効にします。/etc/apt/sources.list の、

# deb-src ...

となっているところのコメントアウトを全部外します。ssh でリモートログインして作業してたのでこうしましたが、デスクトップが使える状態なら「ソフトウェアとアップデート」の「Ubuntu のソフトウェア」タブから「ソースコード」にチェックを入れたほうが早いです。

以下適当な作業ディレクトリを作って作業。

$ sudo apt-get update
$ sudo apt-get install dpkg-dev
$ sudo apt-get build-dep ibus-mozc
$ apt-get source mozc

ここで上のパッチを適用(path/to のところは適当に置き換えてください)。

$ patch -p1 < path/to/mozc-2.23.2815.102-nxkana-20210708.patch

パッチが終わったらビルドします。

$ dpkg-buildpackage -rfakeroot -uc -b

パッチでは changelog は修正していないので元のソースのバージョンと同じバージョンの deb が生成されます。これをそのまま上書きインストールしますが、その前に依存するパッケージをインストールしておきます。途中右往左往して最小限のパッケージがどれだかわからなくなりましたが、emacs と fcitx 関係を入れたのかな…

$ sudo dpkg -i *.deb

mozc のアップデートが降ってくると上書きされてしまいますが、その時は再び上の作業を繰り返す必要があります。

ちなみに最初は changelog に別のバージョンのログを定義してバージョンの違う deb をビルドしていたのですが(-8ubunt1 のところを -8rna1 とかにしてた)、mozc 以外のアップデートが降ってきた時に依存関係のせいなのか元のバージョンに上書きされてしまったので同じバージョンでビルドするようにしました。

キーボードの設定

旧メインPCに繋いでいる HHK (Happy Hacking Keyboard PD-KB02) は、新メインPCの設定が一通り終わるまでは使いたいので予備のキーボードを繋いだのですが、日本語キーボードしかなかったのでインストール時の初期設定は日本語キーボードにしていました。

新PCへの移行の目処がついた時点で HHK を新PCで使うためUSキーボード用の設定に切り替えました。まずコンソールのキーボードを変更。

$ sudo dpkg-reconfigure keyboard-configuration

CUI で設定画面が出るので HappyHacking, English(US) で設定しました。

次にデスクトップにログインして「設定 - 地域と言語」で入力ソースから「日本語」を削除して「英語」を追加して、追加されたエントリをドラッグして先頭に持っていきます。

Shift Space で IME を ON/OFF して入力モードを切り替える派なので、その後 Mozc の設定で「キー設定」をATOKをベースにして以下のように設定しました。

  • 変換前入力中/キャンセル後IMEを無効化 を Shift Space に
  • 直接入力/IMEを有効化 を Shift Space に
  • 入力文字なし/キャンセル後にIMEを無効化 を Shift Space に
  • 入力文字なし/代替空白文字を入力 を Ctrl Shift Space に

デスクトップを一度ログアウトしてログインしなおすと設定が反映されます。これでだいたい思ったとおりの挙動になりました。

emacs の設定

emacs はそのままだとインライン入力(on-the-spot)ができません。ibus-mozc からの入力になり、カーソル位置の下に小さなウィンドウが出てそこに入力文字が表示されて変換・確定して emacs のバッファに入力されることになります。

これは不便なので emacs-mozc パッケージを使いたいのですが、IME の ON/OFF を他のアプリと同じキーで行うには ~/.Xresources に以下の記述が必要です。

Emacs*UseXIM: false

これは X から emacsGUI への IME 入力を無効化する設定です。このあとデスクトップを一度ログアウトしてログインしなおすか、コマンドラインで以下を実行します。

$ xrdb merge ~/.Xresources

あとは ~/.emacs.d/init.el に emacs-mozc の設定をすればいいのですが、素の emacs-mozc は使っているうちに変換候補表示がものすごく重くなることがありました。今でもそうなのかわかりませんが、Ubuntu 18.04 では mozc-popup を入れると解決したので今回も入れます。

まず、melpa からパッケージをインストールできるようにします。

(require 'package)
(add-to-list 'package-archives
             '("melpa" . "https://melpa.org/packages/"))

package-list-package して melpa のパッケージが出てきたら*3 mozc-popup を探してインストールします。

で、これをインストールすると依存パッケージとして emacs-mozc の最新版もインストールされてしまうので、上でやった mozc へのパッチの emacs-mozc の分が台無しになります… しょうがないので、emacs の設定の方で解決します。まず、以下のかな配列テーブルを ~/.emacs.d/ にコピーします。

そして ~/.emacs.d/init.el で以下のように設定しました。

(require 'mozc)
(load-file (expand-file-name "~/.emacs.d/mozc-keymap-kana-101us-nx.el"))
(setq mozc-keymap-kana mozc-keymap-kana-101us-nx)
(set-language-environment "Japanese")
(setq default-input-method "japanese-mozc")
(prefer-coding-system 'utf-8)
(global-set-key (kbd "S-SPC") 'toggle-input-method)
(require 'mozc-popup)
(setq mozc-candidate-style 'popup) ; select popup style.

Shift Space で IME ON/OFF の設定も入っています。

GNOMEEmacsキーバインド

GNOME/GTK アプリで Emacs 風のキーバインドが使えるように設定します。dconf で設定してもいいのですが、ミスに気づきにくくてハマりやすいので GUI の dconf-editor をインストールします。

$ sudo apt install dconf-editor
$ dconf-editor

パスをたどって /org/gnome/desktop/interface/gtk-key-theme を Emacs にします。

xkeysnail のインストール

以下の理由から xkeysnail でキーのリマップを設定します。

HHK の Meta キーの件は以前は xkb の設定で解決していたのですが、面倒なのと、Firefox の件でどっちみち xkeysnail を使うので、キーリマップは xkeysnail に一本化しました。

まずインストール。

$ sudo apt install python3-pip
$ sudo pip3 install xkeysnail

設定ファイルを書きます(xkeysnail-config.py とします)。

import re
from xkeysnail.transform import *

define_modmap({
    Key.MUHENKAN: Key.LEFT_ALT,
    Key.HENKAN: Key.RIGHT_ALT,
})

define_keymap(lambda wm_class: wm_class in ("Firefox"), {
    K("C-n"): with_mark(K("down")),
    K("C-b"): with_mark(K("left")),
}, "Firefox")

前半は HHK のメタキー(◇)を Alt にするための設定、後半は Firefox に Ctrl N と Ctrl B が食われないようにするための設定です。

以下で動作を確認します(path/to のところは適当に置き換えてください)。

$ xhost +SI:localuser:root
$ sudo xkeysnail path/to/xkeysnail-config.py -q

上のように xkeysnail は root 権限で実行する必要があります。以前はデスクトップにログインするたびに sudo のパスワード入力をしていたのですが、面倒なので以下を参考に自動実行するように設定しました。

まずグループの作成とユーザーのグループ設定(hoge (ユーザ名)は適当に置き換えてください)。

sudo groupadd uinput
sudo gpasswd -a hoge input
sudo gpasswd -a hoge uinput

/etc/udev/rules.d/input.rules を作成して以下のように設定。

KERNEL=="event*", NAME="input/%k", MODE="660", GROUP="input"

/etc/udev/rules.d/uinput.rules を作成して以下のように設定。

KERNEL=="uinput", GROUP="uinput"

~/.config/systemd/user/xkeysnail.service を作成して以下のように設定(path/to のところは適当に置き換えてください)。

# 1. Copy this to ~/.config/systemd/user/xkeysnail.service
# 2. systemctl --user enable xkeysnail
#
# Note that you need to set proper $DISPLAY on your environment.

[Unit]
Description=xkeysnail

[Service]
KillMode=process
ExecStart=/usr/local/bin/xkeysnail path/to/xkeysnail-config.py -q
ExecStartPre=/usr/bin/xhost +SI:localuser:root
Type=simple
Restart=always

# Update DISPLAY to be the same as `echo $DISPLAY` on your graphical terminal.
Environment=DISPLAY=:0

[Install]
WantedBy=default.target

xkeysnail の -q オプションは入力したキーをシステムのログに残さないための設定です。こうしないと実質キーロガーになってしまうので…

このサービス有効化します。

$ systemctl --user enable xkeysnail
$ systemctl --user start xkeysnail

一度再起動しないと xkeysnail の起動に失敗するので start はいらないかも。ここまできたらPCを一度再起動します。

再びデスクトップにログインして、以下のようにステータスを確認します(hoge や 1234(ユーザID) や /path/to は適当に読み替えてください)。

$  systemctl --user status xkeysnail
● xkeysnail.service - xkeysnail
     Loaded: loaded (/home/hoge/.config/systemd/user/xkeysnail.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2021-07-05 09:39:27 JST; 16s ago
    Process: 2224863 ExecStartPre=/usr/bin/xhost +SI:localuser:root (code=exited, status=0/SUCCESS)
   Main PID: 2224864 (xkeysnail)
     CGroup: /user.slice/user-1234.slice/user@1234.service/xkeysnail.service
             └─2224864 /usr/bin/python3 /usr/local/bin/xkeysnail /path/to/xkeysnail-config.py -q

 705 09:39:27 keynes systemd[1421]: Starting xkeysnail...
 705 09:39:27 keynes xhost[2224863]: localuser:root being added to access control list
 705 09:39:27 keynes systemd[1421]: Started xkeysnail.

フォントの設定

何かと便利なので Windows と共通のMSコアフォントは入れておきます。

# sudo apt install ttf-mscorefonts-installer

日本語フォントは入ってませんが…

ネットで入手できるフォントはファイルをダブルクリックしてフォントビューアからインストールできますが、数が多くなると面倒なのと、.ttc (TrueType Collection) ファイルはなぜか [インストール] ボタンが無効になってインストールできないのでどうしようかと思っていたところ、~/.local/share/fonts にファイルをコピーするだけでそのまま使えるようになりました。

その他

ruby bundler でデプロイしたスクリプト

このブログを書くのにも使っている HatenaBlogWriter ですが、gem のバージョンを固定するために ruby bundler を使っています。

Ubuntu のデフォルトでは ruby からして入ってないので(python は入ってるのに…) bundler も一緒にインストールします。

sudo apt install ruby
sudo apt install ruby-bundler

旧PCからコピーしたデプロイ先ディレクトリ(/path/to/dir とします)でそのままスクリプトを実行すると、こんな感じのエラーで実行できません。

Traceback (most recent call last):
	2: from /usr/bin/bundle:23:in `<main>'
	1: from /usr/lib/ruby/2.7.0/rubygems.rb:294:in `activate_bin_path'
/usr/lib/ruby/2.7.0/rubygems.rb:275:in `find_spec_for_exe': Could not find 'bundler' (1.16.1) required by your /path/to/dir/Gemfile.lock. (Gem::GemNotFoundException)
To update to the latest version installed on your system, run `bundle update --bundler`.
To install the missing version, run `gem install bundler:1.16.1`

古い bundler で入れた gem はそのままでは動きません。エラーメッセージの指示通り更新します。

$ bundle update --bundler
Fetching gem metadata from https://rubygems.org/.
Fetching rake 10.5.0
Installing rake 10.5.0
Fetching atomutil 0.1.5
Installing atomutil 0.1.5
Using bundler 2.1.4
Warning: the lockfile is being updated to Bundler 2, after which you will be unable to return to Bundler 1.
Bundle updated!

これでスクリプトが動くようになりました。

VLC

デフォルトの動画プレイヤーは対応コーデックが限られているので VLC をインストールしました。

$ sudo apt install vlc

Full-HD 動画の再生も特に問題なし、と思ったのですが、特定の MPEG2 TS ファイルを開くと途中から映像が止まり音声だけ進む状態になり、やがてマウスカーソルも動かなくなりました。音声はそのまま流れます。外から ssh でログインはできるので X だけハングしている状況のようです。

原因の切り分けのためにまず VLC の [ツール - 設定 - ビデオ] で「Output」を「無効」に設定してみたところ、ハングしなくなりました。なぜかウィンドウのサイズが勝手に変わり続けて気持ち悪いのですが、音声は正常ですし、ハングもしません。

では OpenGL 関係の不具合なのか?と思って今度は「ASCII Art」に設定してみたところ、同じ動画の同じ箇所でハングしてしまいました。ということは OpenGL は関係なく、MPEG2 ビデオデコーダーの不具合?

[ツール - 設定 - 入力/コーデック] の Hardware-accelarated decoding はデフォルトで「自動」になっていて、Ryzen APU の場合、ハードウェアデコーダが使用されているものと思われます。そこでこれを「無効」に設定したところ、ハングしなくなりました。

ソフトウェアデコードは重いのでは、と思ったのですが、さすがに 4コア8スレッドの Ryzen だけあって全く気になりません。再生中に Twitter で実況しても特に重くなる場面はありませんでした。CPU 使用率も MPEG2/Full-HD で20%前後、H264 でも10%前後(何故かH264の方が軽い)で CPU 温度も特に問題なかったので、それ以上設定を試さずにこれで行くことにしました。

shotwell

旧PCでは ~/Photos に写真を入れる設定にしていたのですが、旧PCから

  • ~/.local/share/shotwell
  • ~/.cache/shotwell
  • ~/Photos

を同じ場所にそのままコピーすると問題なく移行できました。ただし、Flickr への写真のアップロードの際は再認証が必要でした。何故かパスワードが通らなくて(アカウントが連携している yahoo.com では通るのに)一度パスワードリセットをする必要がありました。

Nextcloud クライアント

クラウドストレージは以前は Dropbox をメインに使っていたのですが、規約改定で無料で連携できるデバイス数が制限されてしまい使い勝手が著しく悪化したので、最近は昔から借りているさくらのレンタルサーバーに Nextcloud をインストールして使っています。

すでに 13GB くらい使っているのですが、さくらのレンタルサーバー(プレミアム)は一度に大量の転送が発生すると 503 エラーを返すようになり、ブログの画像置き場としても同サーバーを使っている身としてはそれは避けたかったので、ローカルでコピーしてから同期することで転送を防ごうとして試行錯誤していました。

最終的には、

  • 旧PC の Nextcloud クライアントを止める
    • 同期フォルダ直下にある以下のファイルが消える(xxxxxxxxxxxx は乱数っぽい文字列)
      • ._sync_xxxxxxxxxxxx.db-shm
      • ._sync_xxxxxxxxxxxx.db-wal
      • ._sync_xxxxxxxxxxxx.db は残る
  • 同期フォルダをまるごと(._sync_xxxxxxxxxxxx.db も含めて)新PCにコピーする
  • 新PCに Nextcloud クライアントをインストール(sudo apt install nextcloud-desktop)
  • nextcloud を起動して認証、同期フォルダ設定

でなんとかなりました。最初は ._sync_xxxxxxxxxxxx.db が残っていると悪さしそうと思って消していたのですが、それをやると逆にほぼ全ファイルを同期しようとしてダメでした。

XSH2

XSH2 は、とあるプロジェクトで使用している perl ベースの言語で、XMLの処理を簡単に記述できるので使っています。Ubuntu のパッケージはないので、CPAN でインストールします。試行錯誤しましたが、以下の手順でインストールできるはずです。*4

まず libxslt1 の開発用パッケージをインストールします。XSH2 が依存する XML-LibXSLT-1.99 がこれを必要とします。

$ sudo apt install libxslt1-dev

cpan を起動します。初回起動時の初期設定はデフォルトのままで進み、まず XML::LibXSLT を notest install します(test で失敗するため)。

cpan[1]> nostest install XML::LibXSLT
Running install for module 'XML::LibXSLT'
  SHLOMIF/XML-LibXSLT-1.99.tar.gz
...
  SHLOMIF/XML-LibXSLT-1.99.tar.gz
  /usr/bin/make install  -- OK

その後 XML::XSH2 を install します。

cpan[1]> nostest install XML::LibXSLT
...

途中、

	Term::ReadLine::Perl::readline(Term::ReadLine::Perl=ARRAY(0x56316edc7470), "Enter arithmetic or Perl expression: ", "exit") called at test.pl line 54
Enter arithmetic or Perl expression: exit

というメッセージが出て止まりますが、そのままリターンキーを押せば最後まで進んでインストールできました。

CPAN の初期設定で変更していないなら、~/perl5/bin/ に xsh がインストールされます。ここには CPAN が .bashrc を変更して PATH を通してあるので、シェルを立ち上げ直せば xsh が起動するようになります。

Stellarium

プラネタリウムソフトの Stellarium ですが、Ubuntu の公式リポジトリからインストールすると何故か少し古いバージョンが入ります。旧PCでは一時期あった月食のバグ(月食中の空を表示すると落ちる)を回避するために公式 PPA からインストールしていた関係で、旧PCの設定ファイルを新PCにコピーしても設定が一部反映されなくなりました。

仕方がないので新PCでも公式 PPA からインストールするようにしました。

$ sudo add-apt-repository ppa:stellarium/stellarium-releases
$ sudo apt-get update
$ sudo apt install stellarium

その後旧PCから ~/.stellarium を丸ごと新PCにコピーしてから stellarium を起動したところ、無事旧PCの設定が反映されました。

astrometry.net

astrometry.net は天体写真から写野の天球上の位置を特定する(plate solve といいます)ためのソフトです。Ubuntu にもパッケージがあるので、apt でインストールします。

$ sudo apt install astrometry.net

しかしこれだけでは計算できません。星表のデータが必要になります。これが膨大で全部で 30GB 以上あるものをダウンロードしなくてはなりません。これも apt でインストールできるので旧PCには全部いれていたのですが、むちゃくち時間がかかるしサーバーにも負荷がかかるので気が引けます。そこで旧PCからデータを丸ごとコピーすることにしました。

astrometry-data- 系パッケージのファイルリストを見ると、tycho2 (ティコ第二星表)も 2mass (Two Micron All-Sky Survey)も、最終的には /usr/share/astrometry/ に fits データを置いているだけのようです(2mass の方は中身はダウンローダーで別のサーバから fits をダウンロードしています)。その他ドキュメントも /usr/share にインストールしていますが、これは動作には関係ないと思われます。

ということで旧PCから /usr/share/astrometry/ の中身だけコピーします。新PC側で、先に sudo で何か実行して認証を済ませてから(そうしないと ssh と sudo のパスワード入力が被って入力できなくなる)以下を実行。

$ ssh rna@OLD_PC 'tar cfp - -C /usr/share/astrometry .'| sudo tar xvf - -C /usr/share/astrometry/

コピー完了後 solve-field コマンドを実行すると無事 plate solve に成功しました。

未解決の問題

indicator-sensors で HDD 温度表示を有効にすると認証を要求される

上の「センサー関係」で書いた通りです。今は udisks2 プラグインを無効にして、必要な時にコンソールから hddtemp を実行しています。あまり激しく温度変化することはないようなので当分これで行きます。

Emacs の表示欠け

Emacs を使っていると時々表示が欠ける(一部の文字が背景色で塗りつぶされる)ことがありました。こんな感じ。

文字単位で消えるわけではなく一部が欠ける感じなのですが、上の動画のように欠け方が大きくてほぼ1行まるまる消えているように見えることもあります。発生条件は不明ですが C-l でスクロール位置を切り替えていると発生することがあります。発生しないこともありますし、そうでない時に発生することもあります。

当該箇所でカーソルを動かしたり範囲選択したりすると表示が復帰しますが、編集中に発生すると文字の消しすぎと勘違いして再入力してしまったりして厄介です。

サウンドのノイズ

これも発生条件が不明なのですが、何かの拍子にサウンドにノイズが入り初めて、システムサウンドも含めてどのアプリから音を鳴らしてもノイズが入るようになってしまいます。ノイズの入った音のあとにエコーのように同じ音が繰り返されるのが特徴です。

気がつくと直っていることもあるのですが、ずっと直らないことも。ベンチマーク中でも何時間も動画を再生していても再現しないので負荷でチップが熱を持って、みたいな話ではなさそう。

再起動後デスクトップにログインしていきなり再現したこともあります。この時は top でプロセスを見ると pulseaudio が 5% ぐらいCPUを食った状態で張り付いていて、pulseaudio の暴走かなと思い以下のコマンドで pulseaudio だけ再起動すると即直りました。

$ pulseaudio -k

とりあえず再発したらこれでしのぎます…

nautilus で SMB のファイルコピーが遅い

Windows の共有フォルダをファイルマネージャー(nautilus)でマウントしてファイルをコピーすると異様に遅いことに気が付きました。1Gbps のネットワークなのに 30〜40MB/s 前後しか出ません。Windows 同士だと 100MB/s 近く出るのですが。

これは困る、と思ったのですが、調べてみると旧PCでも同じくらいしか速度が出ていないことが判明。なら今まで困ってないからいいか… ということで諦めたのですが、一応調べてみると、どうも GNOME の未解決の不具合(制限?)のようです。

nautilus の SMB は gvfs-smb 経由で GIO API を使っているのですが、この時デフォルトの 64KB のブロッサイズが適用されてしまい、性能が出ないとのこと。適切なブロックサイズをオプションで指定すれば性能が出るのは確認済みですが適切なブロックサイズを検出する方法が難しいようでまだ fix されていません。

apt で cifs-utils をインストールして、以下のように正攻法で cifs ファイルシステムとしてマウントするか(マウントポイントは share ユーザ名は hoge とする)、

$ sudo mount -t cifs //windowspc/share/ share -o "username=hoge"

あるいは逆に Ubuntu 側で samba の共有フォルダを作り Windows 側からコピーしてあげるとフルスピードでコピーできるので、それでしのぐことにしました。

デスクトップ壁紙画像が変更できない

デスクトップの背景を変えようと、設定 - 背景 の [画像を追加] で ~/ピクチャ から画像を選ぼうとしても選べませんでした。ファイルダイアログは開くのですが画像を選んでも [開く] ボタンがグレーアウトしたまま。~/Photos の下のファイルでも同様なので日本語パス名の問題ではないようです。

納得行かないのですが、dconf-editor で /org/gnome/desktop/background/picture-url に画像のURLを file:///home/hoge/ピクチャ/cure-marine.jpg のように設定してやれば変更できるので、当分それでしのぐことにしました。

iPhone からの動画のコピーで nautilus が固まる

USB で iPhone を繋いで iPhone 側で「このPCを信頼する」を許可してからUSBを挿し直したら nautilus から写真とドキュメントにアクセスできるようになったのですが、写真から大きな動画をコピーすると nautilus が固まってしまう現象が発生しました。

プログレスバーが進まなくなって転送速度も0KB/s表示になり、nautilus の操作が一切できなくなりました。しかし実際にはコピー自体は進んでいるようで、コピーが終わると nautilus も復帰し、コピーも成功していました。

いまいち納得いきませんが当面我慢して使っていこうと思います。

まとめ

いくつか問題は残りましたが、おおむね旧PCでできていたことは一通りできるようになりました。新PCはさすがに最新のCPUだけあってサクサク動くし気持ちいいです。

今までネットとテキスト編集程度だけなら低スペックのPCで十分って思ってたのですがそんなことはありませんでした。今どきの Web ページ、JavaScript バリバリに使ってるせいもあって、CPUパワー次第でレスポンス全然違いますね… どうせサーバーサイドが重いんでしょ、と諦めてた TwitterFacebook もサクサク動くようになってびっくり。

メモリも 32GB になると安心して使えます。16GB の時は長期間大量のタブが開いた Firefox を放置しているとメモリ残量が気になりだして Firefox を再起動したり Shotwell の同時起動をためらったりしてましたが、今は何も考えずガンガン起動できる感じです。

ということでこれから5年くらいは新PCでなんとかしのげるかな…

長々と書きましたが、正直これ読んで楽しい人なんてほとんどいないと思うんですけど、自作PCLinux やってる人で困った人が検索で見つけてちょっとは役に立ったりすればいいなと思って公開することにしました。実際今回も今までも自分がそうやって助かっているので。

*1:4K では表示がおかしくなるという話もありますが、Ubuntu 20.04 はデフォルトで HWE (HardWare Enablement) スタックのドライバが入るので、現在はインストール後アップデートをかければ直るものと思われます。

*2:なんでそんなにシンボリックリンクがあるのかというと IIIME 関係のソースをビルドした時に生成されたもののようですが、全部特定していらないものを削除したり、いるものは tar で固めたり、というのは大変すぎるので諦めました。

*3:最初 gnu のパッケージしか表示されなくて遅れて出てくることがある。出てこないなら M-x package-initialize したら出てくるようになるかも。

*4:参考: https://stackoverflow.com/questions/28473981/how-to-reinstall-re-run-module-installation-for-a-failed-install-in-perls-mcpa

メインPC新調 (ハードウェア編)

2014年から使っていたメインPCを丸ごと新調しました。Linux (Ubuntu)で使うということもあり、今回も自作です。

旧PC 新PC
CPU Athlon 5350 (4C4T/2.05GHz) Ryzen 3 PRO 4350G (4C8T/3.8GHz)
MB ASRock AM1B-ITX ASRock B550M-ITX/ac
MEM 16GB (DDR3 1600MHz) 32GB (DDR4 3200MHz, ECC)
HDD/SSD WD Red 4TB SSD 960 EVO 500GB / WD Red Plus 4TB
OS Ubuntu 18.04 Ubuntu 20.04
CASE Cooler Master CENTURION 6 (ATX) SSUPD MESHLICIOUS (Mini-ITX)
PSU SUPER FLOWER SF-500P14FG Seasonic FOCUS-GM-550 (550W)
CPU COOLER Thermaltake MeOrb II CRYORIG C7 V2
CASE FAN 12cm+14cm (CASE付属) 12cm x2 (Cooler Master MasterFan SF120M, 山洋 SF12-S4)

パーツの選定

旧PCのパーツは主にツクモから買いましたが、今回は Ryzen PRO 4000 シリーズがマザーボードとセットでしか販売しておらず、組わせられるマザーが店によって限定されている場合があり、目当てのマザーと組み合わせられるアークで揃えました。一部パーツは他の店の方が安かったのですが、同じ店で買った方がサポートで安心かと思って。

CPU の選定基準は、省電力運用できること、ECC に対応していること、内蔵グラフィックがあること、ということで Ryzen PRO シリーズ一択になりました。8月に最新の 5000G シリーズが発売ですが PRO 版がいつ出るかわからないし、そもそも8月まで待つつもりはないので 4000G で。省電力版の 4000GE は一般販売されていないので、4000G を cTDP 設定で 35W にして運用します。

マザーは UEFI (BIOS)で cTDP が設定できる ASRock の製品を選びました。設定場所がなかなかわからなくて苦労しましたが…

ケースは一時期流行ったキューブ型ケース以来の小型ケースですが、これは置く場所がなかったから。旧PCはそのままファイルサーバーとして運用する予定なので机の上しか置く場所がないのでした。HDD が1台しか載りませんがバックアップ等は旧PCをネットワーク越しに使えばOK。小型ケースは昔冷却能力の低さに悩まされてずっと敬遠してきたのですが、全面メッシュならなんとかなるだろう、水冷ラジエーターも対応してるので最悪水冷化も、と。

設置場所の制約で、幅20cm、奥行き30cm、高さ35cm くらいまで、種類が豊富なATX電源が載る、3.5' HDD が最低1台載る、という条件で在庫があるケースはほとんどなくて選択の余地があまりありませんでした。SSUPD は聞いたことのないメーカーだなと思ったら Lian Li のサブブランドということで、それなら作りもきっと大丈夫だろうと思って決めました。

起動ドライブは NVMe SDD にしました。これはサブPCで天体撮影のデータ一時置き場*1に使っていたものを、SSD を新調したのでお下がりで使い回すことにしたものです。交換前に Windows 用のツールで確認するのを忘れていたのですが、総書き込み量はたぶん8TBぐらい。960 EVO 500GB は TBW 200TB なのでまだまだ使えるはず…

/home 用には WD Red Plus を選択。メインPCは基本的に電源を落とさない運用なので NAS 用です。仮想通貨関係の需要による価格高騰が8TB以上ではまだ続いているので4TBを。NAS 用 HDD は東芝が安いのですが、先日録画サーバ用に使ってみたところ、書き込み時のカリカリ鳴る騒音が予想以上にでかくて結局バックアップ用にしたことがあったので… 作業中のカリカリは気にならないのですが、バックグランウドで動かしたまま寝たり動画観たり音楽聴いたりする時はどうしても気になってしまうので。

電源は、旧PCではファンレス電源でしたが、さすがに Mini-ITX ケースでファンレス電源は危険なので、信頼性の高そうな Seasonic の電源を選びました。このへんはあまり詳しくないので 80PLUS GOLD 以上のものからブランドだけ見て適当に選んでます。

CPUファンも詳しくないのですが、35W 運用とはいえ設定がうまくいかなかった場合も考えて 65W 以上対応で、小型ケースで邪魔にならない高さの低いもので、それでいて騒音の少ないものを選んだつもりです。

ケースファンは耐久性と静音性に期待して Cooler Master MasterFan を1個だけ注文したのですが、実際にケースの小ささを目の当たりにして、これはファン1個ではキツそうだな… と思って急遽サブPCのケースファンの交換用にストックしていた山洋の San Ace 12cm を追加投入しました。

組み立て

組み立ては結構苦労して半日かかりました。それとは別に組み立てと設置のスペースを確保するために部屋を片付けるのに2日かかってますが…

まず小型ケースはやっぱり苦労しました。いきなりケースのパネルの開け方がわからなかったのですが、これは戸棚の扉などでよくあるジュラコンキャッチ?式の突起を穴にパチッとはめ込むタイプでした。説明書が入っている箱がケースの中にくくりつけてあって、開け方を調べるために説明書を見ようと思っても開けないと説明書が取り出せないという…

部品の組付け方法が独特なので何をするにも説明書の確認は欠かせません。それでも組付けの順番や制約条件は自分で判断しないとわからないところもあり、途中まで組んでから一度バラしなおしたりという場面もありました。

ケースの工作精度は悪くないですが、板金が薄めでヤワいところがあり、雑な扱いは禁物という印象を受けました。特に 3.5' HDD を取り付ける部分は剛性が足りない感じ。スペース的には2台取り付けられる余裕はあるのですが、重さ的に厳しい印象。

この 3.5' HDD の取り付けですが、今回は内蔵GPUしか使わないので縦に取り付ける長いグラフィックボードとは排他なのは構わないのですが、ケースの中に水平に渡す金具に片持ちで HDD を吊るす形で取り付けるという独特なもの。ゴム製ダンパーが付いているので単周期の振動は発生しにくいようですが、本当に大丈夫なのか…

こういう仕組みなので 3.5' HDD を使うなら横置きは厳禁です。横置きできるとはどこにも書いてないし横置き用の足も付いてないので、設置は縦置きのみですが、マザーボードの組付けのためにケースを横に倒すのも、3.5' HDD を取り付ける前にやらないとダメです。

ちなみに製造不良なのか作業中ミスでネジ穴をナメてしまったのか、3.5' HDD 取り付け金具のケースに組み付けるためのネジ穴の一つにネジを奥までねじ込めないというトラブルがありました。ケースの構造上ネジの頭が出ているとサイドパネルがはまらないはずなのと、ネジを奥まで締め込まないと金具がぐらついて強度的にも振動的にも不安すぎるので焦りました。

無理やりねじ込もうとしても組み付け用の小さな皿ネジは材質的に弱いようで、あまり力を入れると頭の溝が欠けてきて、これは万事休すか、と思ったのですが、付属のネジにサイズとネジピッチが同じで頭がより大きな平ネジがあって、こちらの方が頭が丈夫そうだったので、これをねじ込んでネジ穴をタッピングすることに成功、その後元のネジを奥までねじ込むことができました。

なお MESHLICIOS は 3.5' HDD を取り付けてもライザーケーブルの取り付け位置を変更することで短い PCIe カードなら取り付けられる仕組みですが、ライザーの取り付け位置が変わるため、マザーのスロットとライザーの距離が離れてしまい、付属のライザーケーブルでは届かなくなり、長いライザーケーブルは別売りです。

ケースファンはフロントに 12cm または 14cm を2個取り付け可能ですが、上述の通り1個で済ます予定が、ケースの中が想像以上に密になりそうだったので2個取り付けました。2つとも静音ファンなのと設置場所がデスクから少し離れているのでファンノイズはほぼ気にならないです。

あとはマザーボードへの CPU ファンの取り付けが苦労しました。C7 は樹脂製バックプレートにボルトを通してナットで締めて固定する方式ですが、バックプレートの穴にボルトがなかなか通りません。一本通すと別の一本が外れてしまいます。CPU のコアがむき出しだった時代なら絶対コア欠けしてたな、というレベルでクーラーがガチャガチャ傾いてましたが、最終的にはかなり思い切って力を入れて無事はめ込むことができました。

UEFI(BIOS)設定

組み立て後、モニターとキーボードとLANケーブルを繋いで起動。一回で無事起動しました。ケースにスピーカーが付いていなくて POST コードがわからないので起動後しばらく画面が表示されなくて焦りましたが、待っていると UEFI の画面が表示されました。メモリも SDD も HDD も認識され、ファンセンサーも正常、CPU温度も異常なし。

デフォルトで自動オーバークロックが有効になっているのですが、トラブルの元なのでメモリのクロックだけは定格に固定しておきました。あとは内蔵GPU用のメモリを 1GB 固定に設定して、起動時 Num Lock を無効に。

最初 cTDP の設定が見つけられなくて困っていたのですが、これは後から姉妹板?の A520M-ITX/ac のレビューに書いてあったのと同じ設定項目があって無事設定できました。アドバンスド / AMD CBS/NBIO Common Options / SMU Common Options で System Configuration AM4 を 35W に変更。

ベンチマーク

Ubuntu 20.04 インストール後簡単なベンチマークを実施しました。ハードウェアの性能比較のためではなく、自分の作業環境がどれだけ改善されたかを確認するため、あるいは設定ミス等で異常に性能が落ちていないかを確認するのが目的です。

まず Octane 2.0 です。Firefox 89.0 の新規プロファイルで測定しました。

旧メインPC 4376
新メインPC 19672
サブPC 17456

サブPCは Windows 10 で天体撮影と画像処理、RAW現像、動画編集、ゲームなどに使っているマシンで、CPU は Core i5 6600、GPU は内蔵グラフィック(RAM は 1GB 割当)、メモリは 16GB (DDR4 2133MHz)です。

旧メインPCの4.5倍、サブPCと比べても1割程度速い結果になりました。

次に GPU の性能を見るのに Unigine BenchmarkHeaven。古いベンチマークですが、新しいものは負荷が高すぎて低スペックPCの内蔵グラフィックでは差が分かりづらいのでは思ってこれにしました。

Basic Extream
旧メインPC 170 53
新メインPC 1498 416
サブPC 635 172

もう一つ Linux オンリーですが OepnGL のベンチマークの GL Mark 2 を。

default fullscreen
旧メインPC 930 598
新メインPC 6646 6038

fullscreen は 1920 x 1080 (Full-HD)です。

ECC メモリだと内蔵グラフィックが遅くなるという噂を聞いて心配していたのですが、旧メインPCの 7〜10 倍速いし、Core i5 6600 のサブPCと比べても倍以上速いので、ひょっとしたらこれでも性能出ていないのかもしれないですが、自分の用途には十分すぎるくらの性能は出ているのでこれでよしとします。

結局新メインPCは家にあるPCの中で最速のPCになりました。なお、cTDP が定格(65W)だった時にも同じベンチマークをやりましたが、上の結果とほとんど変わらない結果でした。CPU と GPU 両方負荷かけないと差は出ないのかも。

冷却能力

GPU温度(amdgpu-pci, edge)は Unigine Heaven 実行中に 52℃ まで上昇しました(室温 27℃)。

CPU温度(k10temp-pci, Tdie)は Linux kernel のビルドで全コアに負荷をかけるテストではで 65℃ まで上昇しました(室温 26℃)。まあ許容範囲。

SSDの温度(nvme-pci, Composite)はアイドル時で 39℃、kernel ビルド時で 52℃ まで上昇しました(室温 26℃)。壊れる温度ではないですが、高め。マザー付属のヒートシンクを付けているのですがいまいち冷えていません。

HDDの温度はアイドル時で 36℃、kernel ビルド時で 37℃ まででした(室温 26℃)。

ということで…

ハードウェア自体は問題なく使えそうです。SSD もっと冷えて欲しいですが、作業は基本 HDD 上でやるのでまず問題ないかな。HDD の振動が心配でしたが、今の所問題は起きていません。

Ubuntu 20.04 のインストールと各種ソフトウェアの設定ついては後日エントリをアップします。

追記(2021-07-04): ケースの USB-C 端子について

一つ書き忘れていたことがありました。SSUPD MESHLICIOUS には上面に2つ USB の口がついていて、その片方は Type-C なのですが、マザー側に繋ぐケーブルの先のコネクタが20ピンの小さいやつ(Key A とか Type-E とか呼ばれてるやつ)で、B550M-ITX/ac 上にはこれに対応するヘッダがありませんでした。

マザー上には USB 3.2 Gen1 の19ピンの大きなヘッダがあり、これを20ピンに変換するパーツは1500円程で売っていますが、ヘッダは1つしかなく、Type-A の方に繋いでしまっています。ということで、ケーブルを繋ぐ先がなくて、ケースの Type-C は飾りになってしまいました。

PCIe 拡張カードで Type-E を増設できるやつがあるのですが、背が低いのでブラケットを外してスロットの摩擦だけで固定して無理やり組み込めるかも?でもそうまでしてフロントの Type-C 使いたいかというと…

*1:惑星撮影でCMOSカメラから動画を撮る時の保存先に高速なディスクが必要になるので使っていました。

上野千鶴子氏の東大入学式での祝辞の問題点について (2021/4/22追記あり)

二年前に話題になった上野千鶴子氏の東大入学式での祝辞を読み直す機会があり、今更ながらちょっとびっくりするようなことに気が付きました。初見ではスルーしていたのですが、よく見ると祝辞前半の理屈が全然通っていないのではないか?ということです。

祝辞の前半というのは東大理3の合格率の男女差について述べた以下の部分です。

ご入学おめでとうございます。あなたたちは激烈な競争を勝ち抜いてこの場に来ることができました。

その選抜試験が公正なものであることをあなたたちは疑っておられないと思います。もし不公正であれば、怒りが湧くでしょう。が、しかし、昨年、東京医科大不正入試問題が発覚し、女子学生と浪人生に差別があることが判明しました。文科省が全国81の医科大・医学部の全数調査を実施したところ、女子学生の入りにくさ、すなわち女子学生の合格率に対する男子学生の合格率は平均1.2倍と出ました。問題の東医大は1.29、最高が順天堂大の1.67、上位には昭和大、日本大、慶応大などの私学が並んでいます。1.0よりも低い、すなわち女子学生の方が入りやすい大学には鳥取大、島根大、徳島大、弘前大などの地方国立大医学部が並んでいます。ちなみに東京大学理科3類は1.03、平均よりは低いですが1.0よりは高い、この数字をどう読み解けばよいでしょうか。統計は大事です、それをもとに考察が成り立つのですから。

女子学生が男子学生より合格しにくいのは、男子受験生の成績の方がよいからでしょうか?全国医学部調査結果を公表した文科省の担当者が、こんなコメントを述べています。「男子優位の学部、学科は他に見当たらず、理工系も文系も女子が優位な場合が多い」。ということは、医学部を除く他学部では、女子の入りにくさは1以下であること、医学部が1を越えていることには、なんらかの説明が要ることを意味します。

事実、各種のデータが、女子受験生の偏差値の方が男子受験生より高いことを証明しています。まず第1に女子学生は浪人を避けるために余裕を持って受験先を決める傾向があります。第2に東京大学入学者の女性比率は長期にわたって「2割の壁」を越えません。今年度に至っては18.1%と前年度を下回りました。統計的には偏差値の正規分布に男女差はありませんから、男子学生以上に優秀な女子学生が東大を受験していることになります。第3に、4年制大学進学率そのものに性別によるギャップがあります。2016年度の学校基本調査によれば4年制大学進学率は男子55.6%、女子48.2%と7ポイントもの差があります。この差は成績の差ではありません。「息子は大学まで、娘は短大まで」でよいと考える親の性差別の結果です。

最近ノーベル平和賞受賞者のマララ・ユスフザイさんが日本を訪れて「女子教育」の必要性を訴えました。それはパキスタンにとっては重要だが、日本には無関係でしょうか。「どうせ女の子だし」「しょせん女の子だから」と水をかけ、足を引っ張ることを、aspirationのcooling downすなわち意欲の冷却効果と言います。マララさんのお父さんは、「どうやって娘を育てたか」と訊かれて、「娘の翼を折らないようにしてきた」と答えました。そのとおり、多くの娘たちは、子どもなら誰でも持っている翼を折られてきたのです。

上野氏の前半の理屈は一部混乱があるように思えますが以下のように整理できます。

A. 東大受験の女子の合格率は男子より低い(事実)*1
B. 東大を受験する女子が少ない(事実)
C. 社会には女性差別があり女子の受験が阻まれる(事実)
D. B の理由は C であろう(妥当な推論)
E. よって A の理由は C であろう(???)

よくわからないのは E です。単に A, B, C, D を列挙しただけなら論理的には問題ないのですが*2 A を述べた後「この数字をどう読み解けばよいでしょうか。統計は大事です、それをもとに考察が成り立つのですから。」「なんらかの説明が要ることを意味します」とした後「まず第1に」「第2に」「第3に」と B〜D を主張しているので、B〜D は A が何故なのかを「読み解き」「説明」しており、前半の議論の全体としては E を主張していると解釈するのが自然です。*3

ところが、A は 女子の東大合格率 = 女子の東大合格者数 / 女子の東大受験者数 が男子より低いという主張なのに、B〜D はその分母である「女子の東大受験者数」が少ないという主張しかしておらず、「女子の東大受験者数」が減った割合以上に「女子の東大合格者数」が減る(そうでないと合格率は減りません)理由を全く述べておらず、A の理由の論証として成り立っていないのです。

一方で、上野氏は「女子受験生の偏差値の方が男子受験生より高い」と主張しています。「女子の東大受験者数」が減る際に成績の低い人から東大受験を諦めるので、残った人は成績優秀な上澄みになるからです(以下これを「上澄み効果」と呼びます)。これは妥当な推論だと思います。

しかし、それならば女子の東大合格率は男子より高くならないと辻褄が合いません。辻褄を合わせるには女子が高校での成績が優秀であるにも関わらず受験本番で成績が下がる理由が必要です。ですがそれについて上野氏は何も述べていません。

「意欲の冷却効果」がその理由として提示されているという解釈は可能でしょうか?「意欲の冷却効果」は「どうせ女の子だし」「しょせん女の子だから」という社会の扱いが女子の勉強あるいは受験の意欲を削ぐという話です。

しかし、勉強の意欲が削がれているのなら女子一般の成績は男子一般より落ちるはずです。上野氏は女子受験生の方が男子受験生の方が成績が良いと言っているので、単純に見るとこれは矛盾です。ここは受験の意欲が削がれて受験を諦めた女子が多い中、敢えて受験を決意した女子は優秀な人が多い、と解釈するしかないと思います。

だとすると、結局これは「上澄み効果」の傍証を追加しただけということになり、「上澄み効果」があるにも関わらず女子の東大合格率が下がる理由については何も言っていません。

一体これは何なのでしょう?一つの解釈は、

1. 上野氏は「女子の東大受験者数」が減れば「女子の東大合格率」が下がると勘違いして、E を論証できたと思い込んでいる。

というもの。もう一つの解釈は、

2. E を論証するという素振りはフェイクで、実は「女子の東大合格率」が下がる理由は存在しないことを強調することで東大理3受験には女性差別的な不正があることを仄めかしている。

というものです。あるいは、

3. A の理由を説明する全く別の説明を用意していたが、当日話すのを忘れた。

という解釈もありうるでしょうか?

1 は上野氏の知的能力を疑っているという意味で失礼な解釈ですが、2 は上野氏に悪意があると見做しているのでこれもまた失礼な解釈ではあります。3 は 1 に似ていますが知的能力というよりは認知能力を疑っておりさらに失礼ですね… しかし、上野氏に間違いも悪意も存在しないという解釈はちょっと思い付きません。

もっとも 2 の解釈には問題があります。上野氏の祝辞は全体として東大の教育体制を肯定しているからです。祝辞の後半では「東京大学は変化と多様性に拓かれた大学です」「れから4年間すばらしい教育学習環境があなたたちを待っています。そのすばらしさは、ここで教えた経験のある私が請け合います」などと言って「ようこそ、東京大学へ」という歓迎の言葉で締めているのですから。

これを文字通りに取れば、上野氏は祝辞の前半で E が論証できたと思っている、すなわち合格率が低いのは入試以前の社会の女性差別のせいで入試に不正があったせいではないと思っていることになります。入試に不正があったと思っているならこうはならないでしょう。よって解釈 1 が正解であると。

しかし上野氏ほど知的能力の高い人が一世一代の大事なスピーチで 1 のような勘違いができるものでしょうか?そんなはずはない、とするならば、東大肯定のこの部分を文字通りに受け取ることは不可能になります。その場合、東大肯定部分は言外に「(但し医学部を除く)」という含みのあるものと解釈せざるをえません。

これはやや無理のある解釈ではありますが、上野氏は「社会に出れば、もっとあからさまな性差別が横行しています。東京大学もまた、残念ながらその例のひとつです」と言っており*4 東大の何もかもを肯定しているわけではないので、そういう解釈もありえなくはない、とは言えるでしょう。

また、3 の解釈にも無理があります。この祝辞は東大の公式サイトに掲載された際に「一部事実と異なる表記」を修正しています。3 の解釈が正解ならこの時に話し忘れた部分を加筆するのが自然ではないでしょうか。

今の今まで話し忘れたこと自体気付いてないという可能性もゼロではないですが、そもそも行間からも読み取れない主張を存在するものとして解釈する、しかもそれがどんな主張か全く不明、というのでは文章の解釈とは言えません。文章の解釈とは別次元の擁護論と言わざるを得ないでしょう。

ということで、僕自身は 1 の解釈を取っています。上野氏だって人の子で勘違いはするだろう、と思っているからです。でも上野氏の知的能力を信頼する人ほど 2 の解釈に流れるということはあると思いますし、その解釈を完全に否定することは困難だと思っています。

「ハンロンの剃刀」(無能で十分説明されることに悪意を見出すな)というベストプラクティスに反するとは言えますが、「ハンロンの剃刀」が常に正しいというわけでもないのですから。

なお、僕はこの祝辞は全体としては良いことを言っていると今でも思っています。上野氏は、才能や環境に恵まれ受験競争を勝ち抜いた新入生たちに対して女性差別を例に挙げ「がんばっても報われない社会」の存在を示し、その一方でフェミニストや東大そのものなど限られた範囲ではあれ「がんばったら報われる」環境を作ってきた人に思いを馳せ、そのように生きなさいと言っているのです。

ただ、最初にこれを読んだ時は不正入試を「がんばっても報われない社会」の例として示していて、理3の合格率男女比 1.03 も不正の仄めかしだと思っていました。女子が社会の女性差別の結果、浪人を過剰に避けたり進学を諦めたりするのもまた「がんばっても報われない社会」の独立した例示だと思っていたからです。

でも、今回祝辞を読み直して、どうも理3の合格率問題は不正ではなく社会の女性差別の帰結だと主張しているらしいことに気付いて戸惑った、というわけです。

祝辞の骨子としては依拠する例示が一つ減っただけで、何ら破綻があるわけではありません。しかし、理3の合格率問題を、これは不正なのか?と問いかけつつ、いや不正ではない、という論証に失敗しているというのは、じゃあ不正なのか?という疑問を残してしまうことになります。

実際のところ 1.03 という合格率男女比の偏りは統計的誤差の範囲と解釈可能で、理3の入試に不正はなかった、よって上野氏の祝辞の骨子は揺らがない、と言えると思いますが、1.03 が社会の女性差別の反映であるという主張自体は誤りで、そのことは上野氏の失点と言わざるを得ません。上野氏自身が「統計は大事です」などと言っているのですからなおさらです。

以上、この件については Twitter でもたくさんつぶやきましたが、話が結構ややこしい上、僕自身も頭を整理しきらないままつぶやき散らかしたせいで僕が何を言いたいのかわかりづらいところがあったと思い、改めて論旨を整理してまとめました。

追記(2021/4/22): 「1.03 という合格率男女比の偏りは統計的誤差の範囲と解釈可能」と書きましたが、そうとも言い切れない事に気が付きました。

一見してばらつきの範囲内に見えるのと、「東大理IIIは本当に男子の合格率が高いのか?」で有意差なしとの計算があったのでそう思っていたのですが、そもそもこれは「男女の合格率に差はない」という帰無仮説に対するものです。

しかし上野氏は女子の受験生の方が成績が良いはずだと主張しているので、本来は女子の方が合格率が高いはずなのです。そして男女の成績の差がどれだけあるかわからないのでどれだけなら有意差ありと言えるのかわかりません。

また、東大理3の入試は2018年度から面接が導入されていて、それ以前とはデータの連続性がありません。1.03 というのは2013年度から2018年度までの直近(当時)6年分のデータから算出したもので連続性のないデータが混じっています。

ということで有意差あるなしは簡単には言えなさそうです。不正がある、と言うには有意差があることを立証すべきですが、上野氏は「不正がなくても合格率は女子が不利になる」という話をしようとしているので、本来は必ずしもその必要はありません。

しかし、実際には「不正がなくても合格率は女子が不利になる」の論証に失敗していて、実質「不正がなければ合格率は男女逆転する」という話になってしまっているため、結果的に根拠のない話をしている、という評価になってしまうのだと思います。

*1:ただし、東大理3の合格率の男女比が 1.03 というのは統計的誤差の範囲ではないか?という指摘はあります。しかし上野氏は有意水準を前もって設定していないのでなんとも言えません。有意水準を設定していない=統計的誤差を考慮していないこと、一般的には有意でないとされるのではないかということ、については批判されてしかるべきですが、その点については本エントリでは割愛します。

*2:その場合、論理的には問題はなくても文章構成としては A が投げっぱなしになっていて不自然な構成と言わざるを得ませんが。

*3:例えば墨東公安委員会さんのこの解釈 https://twitter.com/bokukoui/status/1382946024600137731 もそうなっていると思います。

*4:その傍証として、東大の女子比率は博士課程までは増えていくのに研究職になると地位が上がる毎に減っていくことを挙げています。

フィンランド鉄道(VR)の車椅子対応の話とか

はてな匿名ダイアリー(以下慣例にならい個々の日記及びその筆者を「増田」と呼びます)にあったフィンランド鉄道(VR)の車椅子対応の件ですが、

  • 介助が必要な場合はカスタマーサービスに36時間前までに電話で介助スタッフ予約
  • 乗車列車やどんなサポートが必要か事前に伝える
  • サービスの利用は無料

https://www.vr.fi/en/facilities-and-services/accessible-train-travel
はてサが大好きな福祉先進国北欧の車イス対応についてのメモ — https://anond.hatelabo.jp/20210409174921

これについてはてなブックマークコメントで「36時間前までじゃなくて早くて36時間前、遅くて2時間前までに、って書いてない?」と書いたところ、いや、Assistance service at stations には36時間前までに予約って書いてある、との反論があったので補足します。

僕が言ってるのは Commuter traffic ramp service の章にある ramp service のことで、車両とホームの段差にスロープを付けるサービスです。ここには「You can order the service 36 hours before the trip at the earliest and 2 hours before the trip at the latest.」とあり、遅くとも2時間前に連絡を取ることになっています。

で、増田が言ってるのは Assistance service at stations の章にある「The assistance service should be booked 36 hours before the departure time of the train.」のことだと思うのですが、この assistance service というのは、一人で駅を使ったり電車を乗り降りしたりできない人をエスコートするサービスだと思います。

この章の Assistance in boarding the train 以降の節を見ると、出発駅では乗車する車両の席まで連れて行ってくれ、乗り換えでは正しい車両まで案内してくれ、到着駅ではタクシー乗り場やバス停まで案内してくれるようです。また、章の冒頭にはサービスの対象となる人として、高齢者、車椅子使用者、視覚障害者、聴覚障害者、自閉症スペクトラムの人、記憶障害のある人が挙げられています。

増田の「車椅子対応」が何を差すか明確ではありませんが、おそらく伊是名夏子氏の乗車拒否の文脈での話だと思います。伊是名氏は段差さえなければ電動車椅子を操縦して一人で移動でき、段差の解消または迂回を求めているので assistance service が提供するサービスは求めていません。なので、ramp service の方が求めるものに近いのではないでしょうか。

ただし、どちらのサービスも「車椅子を階段で持ち上げて運搬する」というサービスは想定していないと思います。

ramp service は車両とホームの段差にスロープを付けるだけだし、assistance service は「Please note that for security reasons, the assistant cannot lift the customer to or from a wheelchair.」とあって車椅子から利用者を降ろしたり乗せたりしませんし、安全上の理由でそうしないと言うくらいなので車椅子に乗せたまま階段上を運搬するなんてこともしないでしょう。

そもそも駅のアクセシビリティの状況はどうなのかということですが、Tips for a smooth train trip の章には「Most railway stations are primarily accessible.」「Some stations have lifts to make transfers easier.」とあり、駅構内は何らかの形で車椅子での移動が可能と思われます。が、全ての駅でそうなのかは不明です。

最後に伊是名氏の要求についての僕の見解を。

80kg*1電動車椅子を4人がかりとはいえ手で運ぶのはそこそこリスクはあり*2 仮に熱海駅長が断っていても責められるものではないと思っています。

この件は小田原駅の担当者が代替ルートを確保した上で案内する(案内できる体制にしておく)のが適切だったと思います。ただし常に代替ルートが使えるわけではないし、将来エレベーターを設置したとしても事故や災害等でどうしても電動車椅子を階段で運搬する必要も出てくるでしょうから、「モッコ」*3 なり「電ネコ」*4 なりを使って少人数で少しでも安全に運べる準備はあったほうがいいのではないでしょうか。

また、伊是名氏がクレーマーだとか過去の発言等から性格悪いとか思想的にどうなのかみたいなことも言われていますが、公共交通機関というのは性格悪かろうが過激思想の持ち主だろうがなんなら人殺しの過去がある人でさえ乗車拒否なんてしませんししてはいけません。仮に氏への批判が正当なものだったとしても*5そのことと公共交通機関バリアフリーがどうあるべきかというのは別の話です。

追記: 増田は「介助が必要な場合」って書いてるのでそれだけ見ると間違いではないのだけど、assistance service の「assistance 介助」というのは施設上の(いわゆる)バリアフリーでないところを助けるということではなく、バリアフリーの施設であっても利用に支障がある人を助けるためのものだと思うので、文脈上は違う話なのでは、ということです。

*1:100kg説、120kg説などあったが、本人はJ-CASTの取材に80kgと答えている。ブログの写真を見るとおそらく当日使用の車椅子は、さいとう工房のレルミニシリーズ(最軽量のモデルが 83kg) https://saitokobo.com/product/ と思われる。

*2:骨しゃぶりさんのブログ「1台の電動車椅子を持ち運ぶのに何人の駅員が必要か? ただし労働基準法に従うものとする」でも検討されているように安全性の点ではギリギリの条件。

*3:肩ベルトで支えて二人で重量物を運ぶための道具。運送業者は100kg以上の家具やコピー機などをこれで運ぶ。

*4:電動で階段を昇降できる運搬車。100kg以上の荷物の階段での運搬を一人で行うことができる。参照: https://liftkar.net/

*5:個人的には不当なものが圧倒的に多いと思うが。