ConoHaとArch LinuxではじめるLinux

ごあいさつ

Hi, there! はるかみです。

この記事はConoha Advent Calendar 2018の7日目として書かれたものだよ。 いままでChienomiを見たことある人もない人も楽しんでいってね。

基本的にChienomiはedgeな記事を書くことが多いけれど、Advent Calendarのときだけは初心者向けの記事を書いたりしているんだ。 Chienomiでは最近で最もアツかったのは高EQ AIに関する記事だよ!

本当はConoHa WINGに関する記事を書こうかと思ったけど、Advent Calendarで書くようなものじゃないと思ったんだ。 考えていたものは検証に5, 6日必要だとわかったから協賛でもしてもらわないと無理だとわかったんだよ。

それにConoHa WINGでConoHa Advent Calendarのハードルも下がって、今年はWINGに関する記事がたくさん載るだろうからね。え?毒が少ないって?さすがに同じAdvent Calendarの記事に毒を吐くのは来年にとっておくよ。

あなたはLinuxを使っているだろうか。

最近はLinuxというとドヤりツールになっていたり、あるいはミーハーなものになっていたりもする。 あとは、仕事のための箔付けだろうか。

それはLinuxのなんたるかがわかっていない…と思うのだが、ここではそんな話はおいて、とりあえずLinuxを触ってみたいという人のお手伝いをしよう。

この記事にかかれていることはかなりの部分、過去の記事や他で書いたことと重複してしまうのだが、Advent Calendarの記事ということでご容赦願いたい。

今回はLinuxを全く使ったことのないWindowser向けにエクスプレスで進めていく。 スキル不足が直接に迷惑になるサーバー構築ではなく、またデスクトップ用途でもない。

なお、Linuxそのものを体験して評したいのならばメインマシンにLinuxをインストールするよりない。 LinuxのUXはWindowsのそれよりはるかに優れているが、それはさすがにVPSでわかるようなものではない。

また、副次的に性能の低いコンピュータを使っている人の場合、月1000円から2000円程度で強力なコンピュータにオフロードできる、という面でも話していこうと思う。

SSHを用意する

Windows 10では2017 Fall Creator UpdateからOpenSSHが標準採用になっている。ちなみに、2018 Aprilではサーバーも入っている。 とりあえずまだWindows 10ですらない、という人のことはあまり考えたくないので、そこから話を進めよう。

まずはcmdを検索、あるいは“プログラムを指定して実行”からcmd

Windowsでcmd.exeを探す

ssh -VでOpenSSHを確認。

C:\Users\Harukamy>ssh -V
OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4

ssh-keygenで鍵を作成する。 Microsoftが提供するWindowsアプリでありながらUnixスタイルとWindowsスタイルが混在してとてもわかりづらいことになる。 OpenSSHが使うディレクトリは相変わらず%HOME%\.sshなのだが、Explorerでドットファイルが作れないのでコマンドライン上で行う。

>mkdir .ssh

その上でSSH鍵を生成する。

>ssh-keygen -f .ssh/conoha_rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in .ssh/conoha_rsa.
Your public key has been saved on .ssh/conoha_rsa.pub.
The key fingerprint is
SGA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX harukamy@HACKMAN
the key's randomart image is:
+---[RSA 2048]----+
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
+---[RSA 2048]----+

このパスフレーズは秘密鍵を暗号化しておき、使用するときに解除して使用するためのパスフレーズである。 システムが十分に安全かつ強固に保護され、運用されているのであれば(物理的に盗まれることも、ネットワークごしに盗まれることも、ディスクをコピーされたとしても使われることも)ないのであればパスフレーズはなくても構わないし、まず考えられない程度に強固なのであればほどほどに強固なパスフレーズでも構わないだろう。

これでホームディレクトリ以下.ssh/conoha_rsa(秘密鍵)と.ssh/conoha_rsa.pub(公開鍵)のペアが作成される。

Explorerではとてもホームディレクトリにアクセスしづらいので、そこをなんとかしておこう。 ExplorerでC:\Users\ユーザー名に移動し、“クイックアクセス”を右クリックして“現在のフォルダーをクイック アクセスにピン留め”を選択する。

あと、適切なエディタがないのも困るので、インストールしておくといい。 無難なのはみんな大好きNotepad++。

ConoHaでサーバーを立てる

ConoHaでの契約については公式のページをみてほしい。

それではConoHaにログインし、“サーバー追加”からサーバーを追加しよう。 練習用なら512MBで良いだろうし、パフォーマンスオフロードを期待するなら1GB以上にしよう。 OSはもちろん、Arch Linuxである。

ConohaでArch Linuxインスタンスを立てる

Rootパスワードは本当に強固なものにすること。 ここはあまり心配のない部分だが、それでも24文字以上くらいにはして欲しいところだ。

オプションを開き、接続許可ポートを設定する。 IPv4/IPv6ともSSHのみを許可するように設定する。 IPv6のない環境からアクセスするのであればIPv4のみでも構わないし、IPv6でのアクセスが確実な接続形式をとっているのならIPv6のみのほうが良い。

ConohaでポートとSSHキーの設定

そしてSSH Keyセクションは “キーを新規作成” を選択し、“登録方法”に“インポート”を選択する。 そして“パブリックキー”のところに、作成した~/.ssh/conoha_rsa.pub (.pubファイル!!!)の内容をコピペする。

この時点で鍵登録しておくとSSHのパスワード認証が無効化された状態でインスタンスが立つので安全な状態になる。

インスタンスを作成し、起動したら、ConoHaのサーバー一覧からサーバーを開くと“VPS設定”からI逆引きホスト名を知ることができる。

それでは例えばここがv0-0-0-0.a00a.tyo0.static.cnode.ioだと仮定しよう。

SSHでログインする

ではいよいよWindowsに戻ってログインしよう。 OpenSSHの-iオプションに秘密鍵を指定する。引数はSSHのホストだが、その前にユーザーが必要だ。

>ssh -i .ssh/conoha_rsa root@v0-0-0-0.a00a.tyo0.static.cnode.io

ログインできたらexitして一旦SSHを抜ける

# exit

もう少し楽にログインできるように設定をしておこう。 .sshディレクトリにconfigというテキストファイルを作成する。拡張子はない。 UTF-8+LFで編集してくれるエディタを使うのが良いかもしれない。

このファイルは次のような感じだ。

Host conoha-root
  HostName v0-0-0-0.a00a.tyo0.static.cnode.io
  Port 22
  User root
  IdentityFile .ssh\conoha_rsa

これで

>ssh conoha-root

とするだけでログインできるようになる。

OpenSSHが使えない場合

TeraTermを使う方法が公式で紹介されている。

TeraTermの使い方公開鍵の使い方が紹介されている。

ユーザーを作成する

Windowsでは歴史的経緯から曖昧だが、rootユーザーというのは全権を持つ「神」であり、普段使うべきではない。 それどころか、rootのシェルプロセスがあるだけでも望ましくないくらいだ。

Archはインストール時にユーザーを作成しない。自ら作成する必要がある。

ではログインして作業しよう。 ユーザー作成コマンドはuseraddだが、オプションとしては-U(ユーザープライマリグループを作成する), -G(グループを指定する), -m(ホームディレクトリを作成する)を使用する。 このユーザーは管理ユーザーとなるのでwheelグループに加えておこう。

# useradd -U -G users,wheel -m conohachan

ユーザーのパスワードを設定する。とても強固なものが良い。

# passwd conohachan

ユーザー用の鍵を登録しよう。ここではOpenSSHを前提に進める。 Windowsでもうひとつcmdを立ち上げ、先程と同じ要領でキーを作る。

>ssh-keygen -f .ssh/conoha-user_rsa

configを追加する。今度は鍵とユーザーが異なる。

Host conoha
  HostName v0-0-0-0.a00a.tyo0.static.cnode.io
  Port 22
  User conohachan
  IdentityFile .ssh\conoha-user_rsa

鍵をアップロードする。まだrootでしかログインできないので、rootで送る。

>scp .ssh/conoha-user_rsa.pub conoha-root:.

これでConoHaのrootホームディレクトリにコピーされるので、これをSSHに戻ってセットアップする。 まずはユーザーの.sshディレクトリを作る

# mkdir ~conohachan/.ssh

そして、authorized_keysというファイルとして配置する。

# mv conoha-user_rsa.pub ~conohachan/.ssh/authorized_keys

このままだとrootユーザー所有ファイルになってしまうので、直しておく。

# chown -R conohachan:conohachan ~conohachan

.sshディレクトリはオーナーのみアクセス可能であることが求められるため、パーミッションを修正する。

# chmod 700 ~conohachan/.ssh

これでユーザーとしてログイン可能になったはずだ。

>ssh conoha

初期設定

まだrootのセッションも閉じないでおこう。 この状態では管理作業ができるのはrootだけなので、conohachanにも許すようにしたいところだ。

/etc/sudoersというファイルを編集するのだが、これは直接編集してはならない。 visudoというコマンドを使う。エディタにVIが入っていないのでエディタも指定してあげる必要がある。

# EDITOR=nano visudo

下の方にこんな行がある。

# %wheel ALL=(ALL) ALL

このコメントアウトを外しておく。次のように。

%wheel ALL=(ALL) ALL

オーケー。Ctrl+Oして保存し、Ctrl+Xで終了しよう。

ConoHaでは最近、script側でアップデートするようなので不要に思えるけど、一応アップデートしよう。この作業は定期的にしなければならない。

# pacman -Syu

カーネルパッケージ(linuxというパッケージ)が更新対象に含まれていた場合は再起動する。SSHのセッションは切られる。

# reboot

もう少し使いやすく…

とりあえずここからはLinuxを長年使っている身として「それなりに使いやすい環境を整える」ところをやっておきたいと思う。 特にArch Linuxはミニマルなので足りないと感じるものは色々あるだろう。

パッケージを揃える

まずはユーザーログインする。

>ssh conoha
Enter passphrase for key 'C:\Users\harukamy\.ssh\conoha-user_rsa':

$

ちょっとrootでの作業が続くのでrootになる。

$ sudo bash -l
[sudo] password for conohachan: 
# 

サーバーなら必要ないのだけど、まずはユーザーで電源切ったり再起動したりできるようにしておこう。pacmanはArch Linuxのパッケージ管理ソフトウェアであり、ソフトウェアをインストールしたりアンインストールしたりアップグレードしたりできる。

# pacman -S polkit

これでsystemctl poweroffsystemctl rebootがユーザーでできるようになる。

VI, vim, Zshはなくてはならないソフトウェアだ。あと、ターミナルデュプレクサも欲しいのでtmuxも入れておこう。 Zshはgrml-zsh-configパッケージをインストールするとすごく使いやすくなる。 あと、このあとyayを入れる関係でgoとgitも入れておく。

# pacman -S vi vim vim-plugins zsh grml-zsh-config tmux go git

いい感じになってきた。ここで一旦rootを抜け、tmuxを起動する。

# exit
$ tmux

tmuxはプレフィックスキーを押したあとになにかキーを押すとtmuxに対する指示になるようになっている。 デフォルトのプレフィックスキーはCtrl+bで、?を入力することによりキーバインドの一覧が表示される。

とりあえずcが新しいウィンドウを作成するコマンドなので、Ctrl+b Ctrl+cと入力しよう。

これでわかりにくいがふたつのウィンドウができた。nコマンドによりこのウィンドウを行き来できる。

pacmanが扱うことができるのはArch Linuxの公式パッケージだけだ。 AURという、非公式の(しかし、運営自体は公式に行われている)パッケージも扱いたいので、yayというソフトウェアをインストールする。 手順は

  1. Gitを使ってyayのリポジトリをコピー
  2. yayディレクトリに移動
  3. makepkgでパッケージを作成
  4. pacmanで作成したパッケージをインストール
$ git clone 'https://aur.archlinux.org/yay.git'
$ cd yay
$ makepkg
$ sudo pacman -U *.pkg.tar.xz

これでAURのパッケージもインストールすることができる。 もし、yayに不満ならばついでにもうひとつのAURヘルパーであるtrizenもインストールしておこう。pacmanと違い、AURヘルパーはユーザーとして実行する。

$ yay -S trizen

yayやTrizenは公式のパッケージも扱うことができる。

見やすく、使いやすく

まずはすごく簡単な話として、Bashなど投げ捨ててZshにしよう。 Bashなんてゴミだ。

まずは.zshrcを作っておく。

$ touch .zshrc

オーケー。Zshにしよう。

$ chsh
Changing shell for conohachan.
Password: 
New shell [/bin/bash]
> /bin/zsh

chshはログインシェルを変更するだけなので、今のシェルは変更されない。 一刻も早くBashやZshに変えたいので、Zshでログインしよう。

$ zsh -l
%

Poifect! grml-zsh-configをインストールしているのでとても快適に仕上がっているはずだ。 とりあえず途中でわからなくなったら、わかるところまで打ってからTAB連打で切り抜けられる。オプションやオプション引数なんかもだ。 あと、f/b/b<TAB>foo/bar/bazに展開する、なんてこともできるようになる。

さらにZshを強化して、Zshから離れられない体にしてやろう。

$ yay -S zsh-completions zsh-syntax-highlighting

Syntax Highlightを使用するため、.zshrcに次のような記述を行う。 vimが使えるならvimを使えばいいし、ダメならnanoでもいい。

grml-zsh-configはヒストリを辿ったときに「既に第一ワードを入力している場合は第一ワードを確定として、途中の場合は第一ワードの検索開始時カーソル位置までを確定として辿り、カーソルは末尾に移動する」という挙動になっているのだが、「常にカーソル位置までを確定として履歴を辿る」という機能も欲しいのではないだろうか。 というわけで、PgUp/PgDownでそのような検索ができるように.zshrcを追記する。

うーん、beautiful!

さて、ここからはちょっと複雑なことをする。 わかりやすく美しいZshプロンプトのPowerlevel9kを使いたいと思うのだが、これはWindowsだとひと手間ふた手間ある感じだ。

とりあえずインストールだけはしておこう。

$ sudo pacman -S zsh-theme-powerlevel9k

ここからは一旦ログアウトして(各シェルのログアウトしたあとSSHからログアウトするのを忘れずに)Windowsだ。まずはGit for Windowsをインストールする。

これで様々な問題を解消できるようになる。別にMSYS2を入れてもらっても構わないのだが、Git Bashが各種設定を済ませてあるので話が早い。

そして、次にCicaフォントをインストールする。 完全なPowerlineグリフを持っているので話が一番てっとりばやい。このフォント、グリフが豊富で見やすく、制限された状況で本当に便利だ。

で、Git Bashを起動して、右クリックからのOptionsで、フォントをCicaにする。ここまでやっておかないと後で困る。 それではGit Bashからログインしてみよう。

$ ssh conoha

通常Git Bashでも.exeは省略できないのだが、sshはGit Bash側で定義されており、省略できる。

minttyになったことでだいぶ見やすくなったのではないだろうか。Cicaフォントだし。 で、powerlevel9kなのだけど、とりあえず私がサーバーで使っている設定を晒そう。

これはVIモードで使うことを前提にしているので、一般化すると次のような感じか。

で、powerlevel9kなのだけど、とりあえず私がサーバーで使っている設定を晒そう。

grml-zsh-configを使っている関係で先にprompt offするのは必須。 FOREGROUNDとBACKGROUNDの色はお好みで、という感じだ。 Zsh上で(つまり、ログインしたConoha上で)

% for i in {000..255}; do print -P "$i %K{$i}     %k"; done

とやれば、番号ごとにどんな色か把握できる。 もちろん、もっと好みに設定を変更しても構わないだろう。

これも.zshrcに記述する。

この設定は作業中のミスをなくすために行っているもので、実のところ私は普段はPowerlevel9kを使っていない。 だが、SSHから入ったときだけPowerlevel9kになるようにしており、ホストごとに色を変えてある。このことにより、「ローカルホストかリモートホストかを間違える」事故を防止している。

実際、普段はgrmlデフォルト

このホストにSSHで入るとこうなる。

フォントが設定されていないcmd.exeから入ると表示が乱れている。右側のウィジットが次行に表示されているので使えないこともないが…

Git Bashなら正しく表示される。

Powerlevel9kの利用は好みの問題だと思うけれど、Git Bash + Cicaという組み合わせはやって損がないのではないだろうか。

Powerlevel9kの利用は好みの問題だと思うけれど、Git Bash + Cicaという組み合わせはやって損がないのではないだろうか。

自動アップグレード

とりあえず毎日朝6時にアップグレードするようにしてみよう。 Arch LinuxのinitであるSystemdというものを利用する。SystemdにはSystemdタイマーというジョブスケジューラがあるので、これを使うのだが、説明はとても難しいのでとりあえず例示にとどめよう。

rootとして/etc/systemd/update.serviceを作成する。

% sudo nano /etc/systemd/update.service

続いて/etc/systemd/update.timerを作成する。

% sudo nano /etc/systemd/update.timer

時は来たれり

バッチリだ。ここまで来れば、 サービスや他者に迷惑をかけない範囲であれば 君が学んだことを存分に発揮できる場が出来上がったはずだ。

例えばvimを練習したいのなら

% vim vim-training-file

とかやればいいし、Pythonでプログラムを書きたいなら

% vim myfirst.py

とかやればいい。

Linuxについて教えると話は無限に長くなるし、そもそもここまでの一連の作業でそれなりにLinuxに慣れる要素もあったので、Advent Calendarの記事としてはこれくらいで良いではないかと思っている。 この記事のソースファイルはこの行が606行目だし。

というわけで、世の中の人がちょっとでもLinuxに、そしてコンピュータに関心を持ってくれれば幸いだ。 ついでに、こんなふうに簡単にサーバーを立てて、練習やアウトソースにも使えるConoHaは素晴らしいサービスです!(おべっか)

Linuxについての突っ込んだ話はこのChienomiでしているから、関心がある人はぜひチェックして欲しい。 コンピュータやLinuxについて学びたい、教えて欲しいという人はぜひMimir Yokohamaへどうぞ。

それでは今年もこのへんで。はるかみ☆でした♪

蓄積は裏切らない

かつては不安と共に

ここのところかなり難しい…というか、ストレンジなチャレンジが続いていた。 いや、今年は結構その色合いが強かったかもしれない。勝手知ったることよりは未知のことが多かった。

基本的に私は自信家ではなく、分析に寄っているので、評価できない事柄というのは基本的に自信がない、つまりは不安である。

だが、さすがに私はコンピュータ歴も長いし、そのほとんどは学習や非知的生産ではなく道を拓くことに費やしてきた。 なにかをしようとしてつまずきなく成果が出るようになったのはここ2年くらいだと思う。それ以前には相当に案を練ってうまくいく確信があったのに、実際にやってみるとそもそも理屈通りに動かないというようなことで頓挫することがよくあった。

しかし、無駄だとは思わなかった。その過程で被害は大きかったが1、うまくいかないことをネガティブには捉えていなかった。 むしろ、昔とは違う、誰も経験のしたことのないトラブルでも今私は立ち向かえているということに喜びを覚えてすらいた。 不十分な知識と過剰な評価に不安しかなかった昔とは大違いだ、まさに私は今望んだ結果の上に立って戦っていると思えていた。

戦えるようになって、躓きながら前進する

それはひとつの結実だったけれど、ようやく戦えるようになったに過ぎなかった。 表立っての発言をやめ、活動も控えてひたすらに研鑽を積んでまで望んだスタートラインだ。 「いつか私は思い描くものが正しいことを証明していられるときが来るのだろうか」、そう思いながら「本質的には正しいが難なく成功へとはたどり着かない」道を(機械的故障などの不運にも見舞われながら)歩んでいた。

事業をはじめてからはなおのこと色濃かった。得意ではない、むしろできないという確信すらあることに手探りで進む。 何かを信じて目をつぶって飛び込むのはもとより行動力に難のあった私にとってはお得意で、多分最初は音楽家として弟子入りしたときだろう。 「いわゆる社会人としての経験もないけれど、教えてくれる人がいるわけでもないけれど、事業をはじめる」という決断は一見無謀で…しかしながら実際のところ戦えるだけの材料は揃えていた。なにせ、計画は5年も練って準備していたのだ。そのための研鑽だって積んだ。 私の中に判断基準ができるまで丸2年はかかったが、成果のでない中でも確かな手応えは感じていた。

コンピュータでも事業でも、その結実を問う成長の過程がしんどかったことは間違いない。 確かに昔とは違う、戦えているということに喜びを感じながらも、一方でうまくいかないことに苛立ちも感じていた。 もちろん、自分を納得させる方法はある。過去の自分がこのように戦えるかを考えれば一目瞭然ではある。だが、完璧ではない自分につきまとう不安は消えない。

私が不安の中で戦うことを覚えたのはバイクだった。 私はバイクの才能があった。だから、大概のことはできたのだが、これは「最初からできる」から経験による裏打ちがない。 できるという自信はないのだが、やってしまえばできる――という状態は私にとっては未知のものだった。 考えれば考えるほどできる気はしない、が直感はできると囁く。飛び込めば結果になる。だから直感を信じて飛び込む、自分の中にあるものを信じる、ということを私は覚えた。

この世界でもっとも存在する価値がないと信じさせられていた私にとって、超越の境地にたどりついたことは絶望であり、そしてそこからの道は自分に自分を証明するものだった。 冷静な観測者たる私は私に「できるだろう」と言う。いつからか、足は竦まなくなった。

いつのまにか追いついた実力

結実は2017年。ついに私は躓かなくなった。 机上の回答と実践の結果が一致するようになった。そしてついに、「経験のないことの結果を正しく予測できる」ようになった。

未知のことに対する見積もりというのはとても難しい。 だが、業務上、私は過去にやったことのないことをやらねばならないのであり、その見積もり(こちらは金額的な意味だ)というのはやる前に出さなくてはならない――やってから出していたら大赤字だ。 それ以前は結構なミスがあった。軽くみていて実際にやってみたらそんなに簡単な話ではなかったということのほうが多かったが、難しく見積もりすぎていて過剰だったことも1回だけある。 だが、コンピュータのスキルと、なにより経験が高まって考えるべきポイントがわかるようになってきた。仕事の経験を積んで金額の設定を行うポイントが見えるようになってきた。

迎えた2018年、いままでとは異なるタイプの難しい課題が続いた。 このような状況はどこぞのIT企業でも経験しているはずだ。 「今までやっていないことを要望されて、できるかどうか確信は持てないが、なにかしら回答はしなくてはいけない」。 わからないと言うのか、できないと言うのか、難しいと言うのか、調べるからと回答を保留するのか、などなど選択肢は豊富だ。 だが、受ければ私の場合はそこが最終責任なので果たさなくてはいけないし、安易には答えられない。だが、顧客を不安にしないためにもできるだけ正確に、かつ明確な答えを返したいところだ。

今年の難しい課題にはどれも、「検証しなければいけないので確実ではないが、アイディアはあり、できると考えている」という主旨で返している。 だが、この時点で私にとっては未知のテクノロジーも含まれていたし、正確にいえば守備範囲でもなかったので、さすがに確信をもって応えられない…のだが、私のうちには確信があった。「やったこと」はないから今すぐにコードが書けるわけではないが、使うべきツールは思いつくし、実現可能に思えるアプローチもいくつも思いつく。そこまでの責任がなければ「できるはずだ」と言っていただろう。

蓄積が導いてくれる

この感覚というか、嬉しさというかはなかなか伝えるのが難しい。 やったことはないのだ。特にできるという実績もないのだ。だが、確かにできるという感触があるし、その方法というのも私の中にある。調べながらとはいえ、今すぐに検証コードを書き始められるくらい(実際帰宅してそのまま検証コードを書いているし、その検証コードはいずれも理想的に動作した)なのだ。

言うなれば、私の中に、私より格上の私がいて、確信を持ちきれない私に「それはできるよ」と囁かれるような感覚とでも言おうか。 そして、それは確かに事実だ。正規ルートにある経験や実感を飛び越えて、私の中に積み上げられたものが直感となってその解き方を見せてくれる。 それは、根拠のない自信などではなくて、明確に答に導いていてくれていたことはすぐに、浮かんだイメージがどれも正解だったことで明らかだった。

あるいは、個人スポーツで大会でボロ負けしたあと、ひたすら基礎練し、ときどき元トッププロとの練習試合でボロ負けすることを繰り返した末に出場した次の大会で、前回ボロ負けしたはずの強敵が雑魚に感じられてしまう…みたいな感じと言ったほうが伝わるだろうか。

その未知のテクノロジーを扱う中で、予想通りでないことは当然に出てくる。 使ったことのないライブラリの振る舞いを熟知しているはずもない。 その場で試して、予想と違う振る舞いをし、「この方法は使えない」とわかる。 私は、「ちょっとこの方法はダメそうですね」と言うし、今用意していた手が使えないとわかれば、当然「ちょっと難しいですが、なにか方法を考えてみます」と言う――のだが、実際そのときにはもう私の頭は激しく動いていて、既に答らしきものを導きだしていた。 だが、まだそれは言えない。試さなければ確かなものではないし、打ち合わせの場は実験場ではない。責任者としては考えてみるという答は適切だ。 ――果たして、私は正しい答を既に見出していた。「難しい」と言いながら頭の中に浮かんだ式は、まさに望ましく動作した。あまりにも鮮やかに解にたどり着いてしまったがために、「難しいですね」と言いながらちょっと上の空はご愛嬌…ということにしていただきたい。

私がいつの間にそんな境地にたどり着いたのか、正直よくわからない。 コンピュータを追求したことのある身であればわかるだろうが、コンピュータにおいて「正しかろう」ことを考えることと、考えることが正しいことには著しい差がある。正しいと思ったことは大概一発ではうまくいかないし、一発でうまくいくことなんて本当に珍しい。

はずなのだが、私はそのことについて考えはじめたときには答がどこにあるかは見えている状態になってしまったわけだ。 まるで優秀な科学者のようではないか!!2

特に私に明確な成長の実感や、特別な自信があるわけではない。 どちらかといえば、その応答の根拠になった見積もりには自信がなかった。「思いついたものが間違っていたら、ちゃんと方法を思いつくだろうか。できそうな気はするけれども…」程度の気持ちで回答しているわけだ。 ところが、その回答を用意する間に実際には答が見えてしまっている。

つまり私の地力は、私が思う以上に確かなものになっていて、慎重な私の見積もりに反して、確かな答にたどりつくことができるだけのものになっていた。 それを為し得たのは、私がずっと成長や進歩を感じることができないまま、ずっと戦い、躓き続けてきた中で積み上げてきたものがそうさせるのだろう。

だから、改めてすごく実感した。 例え確かな実感がなくても、そうやって積み重ねてきたものは、蓄積は、裏切らない。 確かな力になっているのだと。


  1. 最も大きいのはやはりLUKSが解除不能になりかなり多くのデータを損失したことだろう。

  2. 「随分と難しいことを言うな君は。そんなことしたこともないからわかるわけがないだろう。 …いや、でもそうだな…あれをこうして…いや、そうだとあれが問題になるから… あぁ、そうだな。ちょっと思いついたことがあるんだ」 みたいな感じ。

21.5インチFHDと32インチ 4kディスプレイをLinuxで混ぜる

なにをしたか

あらまし

私はディスプレイは「随時買い足す」スタイルできた。 それも、主にリサイクルショップで買い集める形だ。

台数が多く、並行作業も多いので、接続数の関係上どうしてもディスプレイが増えざるをえない。

そうした中、ずっとメイン環境を支えてきたのがLGの22EN33及び22EN43である。 支えてきた、と言うと良さそうに聞こえるが、私にとっては最悪なディスプレイである。 輝度調節がおかしいし、色味も最初からぶっとんでいて調整の意味がない。挙げ句、ドット抜けはあるし、ちょっと触れただけでも傷はつくし、アダプタは激しくコイル鳴きするし、一度は液晶抜けするし、LGのサポートは「何も問題はない」と突っぱねるし、もう二度とLGのディスプレイは買わないと心に決めるくらいはひどかった。 似たようなサムスンのS22B300は非常に素晴らしいディスプレイなので、サムスンがPCディスプレイをやめたのが残念でならない。

基本的に輝度や色味などのぶっとび度合いは22EN33のほうが悪いが、傷がついたりドット抜けしたり壊れたりとトラブルが多いのは圧倒的に22EN43である。そして、その22EN43が、ついに画面全体に乳白色の何かを浮かべるようになってしまった。

困ったものだと思っていたところ、なんだかちょうどよくアウトレット品の4kディスプレイ、AcerのET322QKがえらい安くで出ていたので即決してきた。

解説

これは、もうちょっと説明がいるだろう。

私のディスプレイは圧倒的に21.5インチFHDが多いが、これはFHDディスプレイとしては安いためである。叩き売られることも多いし、中古も潤沢だ。

基本的にはやや小さいが、DPIとしては101ないし102程度であるため、これ以上大きいと96を下回ってしまう。解像度的には無難な線だ。

4kに変更したい、というのはずーーーっと前から思っていたこと(10万円くらいの4kディスプレイが出始めた頃から)なのだけど、その場合27インチを本命としていた。 これは、視線移動量と視点距離を考えたときにこれ以上大きくなってほしくないからだ。 一方、21.5インチや24インチの場合、4kになることで密度が上がり、必然的に多くの情報を表示できることから、より色々と表示できるし、ウィンドウのクォータータイリングも現実的になる…はずなのだが、24インチや21.5インチの4kではあまりにも表示サイズが物理的に小さいため、結局左右タイルが限界であり、あまり情報量が増えない。 27インチもまぁまぁきついが並べるには限界サイズである。

私のディスプレイは基本的にメイン2+サブ1という使い方なのだが、今回は事情が事情だし、2枚は買えない。 そこで1枚だけ置き換えるのだが、そうするとメインディスプレイ同士で表示サイズが著しく違うという事態が生じる。

32インチはちょっと大きすぎるが、おけないこともない(32インチ2枚は机のサイズを考えても現実的でないくらいは厳しい)し、DPI差が小さく、妥協できるセッティングが出しやすい――このことはこの記事のこのあとの話で延々触れる。

ちなみに、アウトレット(展示品)というといまいち感があるが、ディスプレイの場合保証があったところで対応されづらいのが現実である上、対応されることのないドット抜けや表面の擦り傷というのがあって賭けみたいなところもあるので、動いている実物をチェックした上で買えるのはむしろメリットだと思っている。

今回は、これまで理解はしていたが、実際に混ぜてみたことで改めて実感したことを述べていこう。 もちろん、Linux前提である。

小さい? 大きい?

実測値としてはLG 22EN43は幅47.7cmで1920px (102dpi)、 ET322QKは幅69.3cmで3840px (140dpi) である。

102 / 140 = 0.728571427571… であるため、ドットは72.857%(約3/4)に小さくなったことになる。

逆に、ET322QKをFHD表示にした場合は145.71%に拡大されることになる。これは、単純に21.5インチディスプレイから同一解像度(FHD)のまま32インチディスプレイに変更した場合と同様のことである。

これは一辺を見た数字だし、基本的にコンピュータ上で表示されるものというのはボックス状なので、面積で言うと53.08%まで小さくなっているのでだいたい「半分になった」という感覚だし、FHDのままだと212.31%と「倍になった」感じがする。もちろん、ディスプレイの表示面の面積自体倍以上に大きくなっている。

これをまぜたとき、FHDで統一するともちろん4kディスプレイのほうが物理的に大きいぶん大きく表示される(倍以上に!!)のだが、実はこちらはあまり気にならない。 「大きいテレビで引き伸ばされた画面を見る」というようなことに慣れているからだろうか。実際、その画面を見ると「ギザギザでぼんやりしているなぁ」と私は思うのだが、でもそこまでみづらいということもない不思議だ。

ところが、FHDで適性なサイズにしている状態で4kに表示させると表示サイズが半分になっていながら表示する空間は4倍ある(表示可能な量は4倍にしかなっていないのだが、「半分のサイズで表示されている」「空間は4倍になった」というそれぞれ別の感覚が相乗効果を発揮する)のでやたらがらんとして見えるし、やはり適正サイズの半分というのは小さすぎる。 高密度になっているので意外と文字も読めるは読めるのだが、しかしながら非常にきつい。4kを4kとして運用する以上、元のままのスケールではちょっとやっていられない。

ちなみに、32インチのディスプレイは問答無用で大きい。一枚だけ使うにしてもかなり距離がないと大きすぎるくらいで、マルチディスプレイするサイズではないな、と感じる。

混ぜる場合どうスケールさせる?

4kのほうがいいディスプレイだし、物理的にも大きいので4kをメインに考えるべきだろうと思うのだけど、 72.857%ということは、元の状態でスケールしていなかったとしたらだいたい1.4倍にするとFHD側の元の状態と同じ物理サイズになる。1.5倍だとちょっと大きい。

ところが、1.4倍にスケールさせてしまうと、FHDの論理ピクセル数は1370となるため、HD(FWXGA)と同等になる。縦は771ピクセルである。 21.5インチのHDディスプレイというのは実在したが、ちょっと狭い。ウィンドウをタイルして並べるとやたら文字も大きく表示領域がまるで足りない感覚になる。

だから、間をとって1.2倍(あるいは1.25倍)というのがよさそうではある。フォントサイズは少し大きめにしたほうがいいかもしれない。4k側で文字が小さく感じるかもしれないし、部品が多少小さくなるのに比べて文字が小さくなる影響は大きいからだ。

1.2倍スケールの場合FHDの論理ピクセル数は横1600ピクセル、1.25倍スケールの場合1536ピクセルになる。1.25倍だとちょっと狭いが、1.2倍ピクセルなら「なんか表示が大きい」程度で済ませることもできそうな感じである。 MacなんかはUIが大きくぎっしり表示されるので、それが気にならない人は普通にいるだろうし、悪くないかもしれない。

試した結果は結局「間をとる」という無難な結論になってしまった。

ちなみに、今回の場合21.5インチFHDが2枚で32インチ4kが1枚という構成であるためにあまりFHD側を無視するわけにもいかなかったが、これが4k2枚でFHDが補助ディスプレイであるという話であれば1.4倍スケールでも別に構わないだろう。1370ピクセルあればウィンドウを常に最大化してしまえばそんなに気にならない、というか、そもそもラップトップが実DPIに合わせてスケールするとそれよりも小さくなるのが普通なので(私のThinkPad X1 Carbon(14インチ FHD)は148DPIでスケールされているため論理ピクセル数は1228である)表示スペースが足りずにはみだすようなことはあまりない。

それぞれスケールできない?

できない、らしい。

Windowsだとディスプレイごとに「拡大率」という値を設定できるようになっている。 この拡大というのはまんまスケーリングを意味しているので、ここで175%を設定すると論理1ピクセルに対して1.75ピクセルをカウントするようになる。

だが、この設定が今のところLinuxでは上手くできない。 最もスケーリングが細かくできるのはKDE Plasmaだが、それでもディスプレイごとに独立した設定はできないようになっているようだ。

xrandrを使うことで設定自体は可能だが、少数の値を設定してしまうとフォントがすごく汚く表示されることになる。

だから、現時点ではディスプレイごとのDPI差を適切に埋める完璧な方法はない、ということになるだろう。

フォントだけ合わせるという方法

今回の場合、51.6%に縮小されるもののUIのサイズとしてたいていの場合は51.6%というのは私にとっては許容できるサイズに収まった。

そこで、私がとった方法がこれだ。

実DPIによる影響が最も大きいのは「文字サイズ」であるため、LinuxでもUIスケーリングとは別にフォントはスケーリングできるようになっている。

そして、フォントのスケーリングの構造はちょっとめんどくさい。

フォントの場合96を1として、設定されたDPIの倍率にスケールされる。 つまり、144DPIを設定した場合、144 / 96 = 1.5 なので、1.5倍にスケールされる。

フォントにおける1は1ピクセルであり、1ポイントでもあるのだが、両者は同時にスケールされることになり、基本的には同一視できる。 FontConfigは144DPIを設定した場合、16pxを求めても、16ptを求めても、24実ピクセルで描画する。 問題はビットマップフォントを使う場合だが、その話は割愛する。

基本的に115.2DPIにすれば1.2倍スケールとなる。120DPIで1.25倍スケールだ。 UIと比べ柔軟に設定できるので、このあたりを参考にバランス良い設定になりそうなDPIを設定すると文字側は調整できる。

私は今のところ120-136DPIの範囲で様子を見ている感じだ。 KDE Plasmaの場合、ほとんどのアプリケーションはPlasma Workspace側で設定されたDPIに従うが、ConkyはFontConfig設定ファイルを尊重するため、Conkyのサイズ調整を目的に異なった値を設定する方法もある。

あとは、積極的にフォント側DPIを設定してからUIスケーリングでバランスをとる、という方法もある。 この方法はもっと実DPIに差がある場合の解消方法として使える。 また、フォントのみで解決する場合は細かなUIスケーリングがいらないため、「Hi-DPIのためにKDE Plasmaを使わなくてはならない」という状況を避けられる。 (KDE Plasmaは0.1倍単位でUIスケールできる)

もはや、DPIとかピクセルとかポイントとかいう、定義が明確であるはずの言葉が相対的なものになってしまっていて意味がわからないが。

なお、フォント設定でスケールする場合に特に重要なこととして、「普段GTKデスクトップを使っていて、スケーリングのためにKDE Plasmaにスイッチした人」は、.xprofileなどでexport QT_QPA_PLATFORMTHEME=qt5ctとかしているのであれば、それをやめないとKDEの設定がちゃんと反映されず、GTK2アプリケーションにも反映されない。

また、この方法を取る場合、パネルだけはCinnamonもPlasma Workspaceも高さがピクセル単位になっているため大幅に小さくなってしまう。このため、パネルの高さは再調整が必要だ。 私の場合、サブディスプレイ上にパネルを置いているため問題はなかった。

ブラウザのスケーリング

ウェブブラウザはちょっと特殊な事情を持っているようだ。

Chromium系(ChromeもVivaldiも)ブラウザはフォントのDPI値が約110%以上(103以上?)であるとき、そのDPI値に合わせて10%単位でスケールするようだ。 これはブラウザをズームしたときと同じ挙動だが、困る場合がある。

これによってパーツがはみ出してみづらい場合があるが、これについてはまだズームを落とせばいいので許せる。 問題はフラゲ(フラッシュゲーム)である。 見た目が汚くなる上に動作が遅くなって非常に辛い。

なお、Firefoxはまた事情が違うのだが、layout.css.devPixelsPerPx1にすれば自動スケールは行われなく成り、-1にすると自動的にスケールされる(多分、UIスケールによるのだが、DPIによるのかもしれない)。この機能に関してはlayout.css.dpiも絡む。

実際、メイン/大きな4k * 1 + サブ/小さなFHD * 2 ってどう

だめ。 どうしたってみんな4kを取り合ってしまう。

なにをするにも大概大きい4kっていうのは便利で、できればそこに置きたいという気持ちが強い。 みっちり書かれている文章だとそうでもない(FHDの全画面表示でもテキスト量が多すぎる)けれども、なにかしら情報が付属していたりマルチペインだったりするのが現代なので、たいていのアプリケーション及びコンテンツが4kを奪い合う。

サブは私の場合メール, Discord, Twitterなんかになるのだけど、これらは基本的にリアルタイムで見続けるようなものでもないからそれぞれ全画面化してサブに置いているものの、4kだったらモニタリング機能とか作ってタイルして色々表示させてもいい。

だから特に必要ないものも含めてたいていのアプリケーションは大きな4k(もちろん、適切な大きさの)を欲しがる。 21.5 FHDを回転させて縦にするとバランスはいいが、表示できるものはさらに少なくなる。

32インチを複数置くのは難しいので、やはり27インチ4k*2 + 21.5もしくは24インチFHDというのがバランスがいいと思う。 逆にサブを32インチ4kにして少し離してモニタリングに使う手もあるけど。

Acer ET322QKってどう (2018-12-03 追記)

基本的には悪くないと思う。 少なくとも22EN43/22EN33のように色味がおかしくて輝度もおかしくて視野角も異様に狭いといった問題はない。 特別良いということもないけれど、かといって目立った問題があるわけでもない。

特別良いというわけではなく、色味も標準(というフラット設定)ではフラットではないため、アートワークの作業をするクリエイターにはとても耐えないし、ゲーマーにも無理だろうけれど、 動画視聴程度であれば遅延が気になるということはないし(ただビデオカードのほうは4kなのでちょっと重いけど)。

色味も、特に優れたところはないけれど、別に使えないことはない。一応sRGB 100%らしいので、カラーキャリブレーションすれば結構使えるのかもしれない。

目立った問題としては入力端子が3系統(HDMI 2.0×2, DP 1.2×1)であることだろう。 台数が多いとなるべく集約したいので、端子はなるべく欲しい。 私の環境だとDVI-Iが多いけど、別にDVI-ItoHDMIは可能なのでHDMIで良しとして…

メーカー モデル ポート
IO DATA EX-LD4K271DB D-Sub, HDMI(2), HDMI 2.0, DP
IO DATA KH2750V-UHD D-Sub, HDMI(2), HDMI 2.0, DP
BenQ EL2870U HDMI 2.0(2), DP
LG 27UK650-W HDMI(2), DP
iiyama ProLite B2875UHSU B2875UHSU-B1 DVI, D-Sub, HDMI 2.0, DP
JAPANNEXT JN-IPS27FLUHD HDMI 2.0(2), DP(2)
DELL S2817Q HDMI(2), DP, miniDP
ASUS VP28UQG HDMI 2.0(2), DP

JAPANNEXTがIPSで消費電力も最大35Wと低いのに安くてなんか強い。 それはともかくとして、以前のように端子数5を越えるものは減っている感じだけど、3というのは結構少なめ。 端子数4は普通に狙えるので、そこは残念ポイントな感じがする。

最大の難点は、起動が遅いということだろう。 EIZOとかも遅いので、品質の問題ではないけれど、結構遅い。そして、切り替えも遅い。信号がなくなってから再び信号を捉えるまでが長い。

「待てばいいじゃん」と思うかもしれないが、実は KDE Plasmaでは深刻な問題になる

KDE Plasmaで思わぬ問題 (2018-12-03 追記)

KDE Plasmaの場合、ディスプレイに対してディスプレイの接続方法ではなく、「ディスプレイの認識上の番号で」識別する。 KDE Plasmaはディスプレイを中途半端に重ねることも可能で柔軟なのはいいのだが、応答の早いLG及びサムスンのディスプレイはすぐつくのだが、このときKDE Plasmaは「ディスプレイが2台しか接続されていないように見間違う」。

つまり、左から

  • LG HD
  • ET332QK
  • サムスン HD

と並んでいて、パネルはサムスンの上にあるのだが、 このときこの並び順に最初にKDEにログインした時点では認識されている。 だから、パネルは3番ディスプレイにある。

ところが、一時ブランクスクリーンになって復帰すると、ET332QKの認識が遅れるためにサムスンが2番になり、ET332QKが3番になる。 結果としてサムスンとET332QKの壁紙が入れ替わり、パネルはET332QK上に移動してしまう。 さらに、なぜか中心座標を見失ってしまって、Conkyが1920pxずれる。

3台であれば右にあるディスプレイをプライマリディスプレイにすることで1番を固定すればET332QKが最後にくるように固定できるから問題は軽減される。 だが、アンバランスな配置のせいかPlasmashellがバグることが多い。さらに、どうしても左側のディスプレイをy:1081に固定するのが難しい。y:0になってしまう。

また、マルチディスプレイではKDEはフルスクリーンにしたときにパネルの表示がおかしくなる。 パネルの表示の上に古いパネルの表示がかさねられたようになる。つまり、以前同アプリケーションでフルスクリーンにしたときと同じ状態になる。 確実になるわけではないが、一度発生するとフルスクリーンにするたびに再現しつづける。

結局、私はCinnamonに戻した。 フォントのスケーリングを中心としてUIスケーリングしないことにしたため、これでも問題はない。

CinnamonのフォントスケーリングはDPIではなく倍率になっている。 0.1倍単位だが、1.25倍で120DPI, 0.1倍あたり9.6DPIというのを基準に考えれば良いだろう。 今の状況を考えるとこちらのほうが素直だろう。

このままではQTアプリケーションが小さいので、.xprofileQT_SCALE_FACTORを設定しておくと良いだろう。 1.2とか1.25あたりが無難な値になるだろうか。

ところがCinnamonでも… 原因はDP (2018-12-05 追記)

Cinnamonなら大丈夫と油断していたところ、Cinnamonでもブランクスクリーンに落ちるとおかしなことになってしまった。 パネルがおかしくなるといったことはないのでKDE Plasmaよりはマシではあるものの、好ましい状態ではない。

どうも他のディスプレイでは発生しない症状として、「電源がオフになると切断される」らしく、問題はディスプレイの電源を切っても発生する。 そして調べていくと、「DPの仕様」らしいとわかった。なるほど、確かに他の2台はminiDP→DVI-Iで接続しているのでDPではささっていない。

WindowsだろうがLinuxだろうが、ディスプレイのホットプラグで問題が生じないなんてことはないので、これは大迷惑である。ディスプレイを共有して作業していることなんて普通にあるのだし… 実際、この挙動は相当強く嫌われているようだ。

なんとかしようとがんばって/etc/X11/xorg.conf.d/90-mhwd.conf

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
        Option "NoLogo" "1"
        Option "UseHotplugEvents" "false"
        Option "AllowEmptyInitialConfiguration" "true"
EndSection

などと書いてみたものの残念ながら効果はなし。

ただ、この場合問題ははっきりしているので、本気になればやりようはある話だと思う。 とりあえずは私の場合ディスプレイの電源を切らないように設定してしのいでいるが、困るのは「通し作業のときにディスプレイを切って節電する」という方法がとれないことだと思う。

そのうち何か考えて対応したい。

4GBの人権

ことの起こり

最近「会社の支給PCのメモリが4GBであることが悪行である程度」が話題になっている。 もちろん、これが意味するのは「会社の支給PCのメモリが4GBであることは許されざる罪である」という点に関しては異論を差し挟む者は基本的にいない。

この手のことは何度か話題になっているのだけど、今回特段話題になっているのは論点が広がったためであると思う。 今までは「エンジニアのPCがメモリ4GB」という話題だったのだが、ここにきてそれ以外にも

  • バックオフィスのメモリは4GBでいいのか
  • エンジニアとオフィスワーカーのスペックに差があって良いのか
  • 16GBのマシンを支給しているところは名乗り出てみろ、の煽り → タイミングよくサイボウズがバックオフィスにも32GBを支給していると公表

おおまかにはNTTがGAFAに引き抜かれてて処遇改善を考えているよ、という話と、NTTをやめてGoogleに行った人のブログがバズったから…というところにあると思う。

なお、今回の記事の基本的なところはLinuxのメモリの本当の必要量を考える(メモ)を読んでほしい。

自己紹介

私が使っているマシンは今かなり幅広い。普段から使っているものだけに限定しても

  • 40コア IntelスケーラブルXeon (Skylake) / 128GB RAM
  • 4コア Xeon (Bloomfield) / 20GB RAM
  • 4コア APU (Godavari) / 32GB RAM
  • (サーバー) 2コア Turion II Neo (Geneva) / 2GB RAM
  • (ラップトップ) 4コア Core i5 (Kabylake) / 8GB RAM
  • (ラップトップ) 2コア Celeron (Haswell) / 16GB RAM
  • (タブレットPC) 4コア Atom (Bay Trail) / 2GB RAM
  • (ラップトップ, ルーター使用) 1コア Celeron(Netburst) / 1GB RAM

とかなり様々だ。

メモリ4GBのマシンがタブレット(実体はPavilion x2 10-j000)とサーバーしかないが、実際のところマシンラインナップとしてはもっと色々あって2GB/4GBのマシンも何台かあるし、そもそも先代主力機だったBloomfield Xeonワークステーションは結構な間4GB RAMでがんばっていた。

そもそも、Turionのサーバーはメインマシンの不調やシステムの組み直しで結構な期間(トータルで3ヶ月くらい)メインマシンを担ったことがある。しかも最近の話である。

なお、OSはタブレットだけがWindows 10で、他は全てManjaro Linuxなのであまり参考にならないだろう。

使用マシンの経験も幅広い。最初に使ったのはIBM JX3だし、RAMはわずか128kB(単位に注意)でしかなかった。さのあとのSunワークステーションはなにするにもパワー不足だったし、AptivaはOSの起動すら危うかった。 ようやくひと心地つけたのは当時ハイエンドクラスだったVAIOだけれど、メモリは64MBにすぎず、やはりなにをするにも足りなかった。

そして今でも192MBに拡張したもののVAIOは現役だし、練習機のメモリは1GBである。

一方で今の40コアXeonに代表されるように一般的なPCの次元からは逸脱したマシンの利用歴もある。 さすがに現役でEPYCを使っている人にはかなわないが、それでも有り余る性能を使い切るような経験もある。

普通の人が経験するよりもずっと幅広いマシンで、そのマシンでできる限界の作業をするという経験 をたくさん積んでいる、と言えるだろう。

また、私はメモリの利用状態を常にConkyで監視しているし、一定以上に高まったときにはメモリの利用状況をダンプする(自動で行われるものと、ワンクリックで実行できるものの2種類。実行内容は/proc/meminfopmap -xによるもの)という運用をしている。 つまり、メモリの使用量というのは一般に感覚やメーターで把握するよりはかなり厳密に把握している。

「メモリの使い方」の話

適切さの話は置いておいて、「エンジニアが4GBでまともに仕事ができない」というのは、特に個人的なコンピュータが4GBで使えないというのは、私としては無能な印象を受ける。

実際、Manjaro Linuxは結構「全部盛り」方向の環境なのだが、それでもブート時はそれほど重くない。 XFce4, Cinnamon, KDE Plasmaいずれでもだいたい1GB前後、せいぜい1.3GBといったところである。そして、このまま普通に(タスク切り替えで)利用していても4GBを突破することはあまりない。

私にしてみれば、制限的環境としては4GBというのはものすごく余裕がある。 普通にAtomやVSCodeも使えるし、Chromiumでウェブブラウジングもできる。 これが2GBになるといきなりきつい。実用的なデスクトップ環境だと1GB近くメモリを使ってしまうので、Chromiumでブラウジングするともたない。「Chromiumを諦める」でも「デスクトップを制限する」でも使い勝手に非常に大きな影響を感じる。

だが、4GBあれば普通に使える。 といっても、「4GBを前提としていれば」だ。 「あまりメモリを使わない使い方をする」ことによって「4GBで不足することは稀である」という状況を作り出せるという話なので、ある程度のスキルがいる。 つまり、一般エンドユーザーにとっては4GBというのは難しい。だから、事務職に4GBのPCを与えるのは率直に言って罪な無知である。

だが、エンジニアだと話は違う。4GBで作業に支障をきたす、というのは修練が足りない。 4GBという枠を与えられてその枠内に抑えた進め方ができないということは、開発しているものが許容されるパフォーマンスの制限やリソースの制限に収めた最善を尽くすことができないということなので、その意味でも能力の欠如を晒すことになる。

前提が変わる要素は多い

言うまでもなくこれにはいくつかの観点がある。

まず、4GBで「十分でない」ことは明らかなのである。

そもそもメモリの性質を考えてみよう。メモリというのは余っていることによってなにか嬉しい効果があるわけではない。もちろん、使っていて余剰があればそれをさらに使うことはできるが、つかっていないのであれば余っているものは余っているだけなのだ。 だから、「足りなければ工夫する、余っていれば使い方を増やす」というのが基本になる。 そして、「工夫しなければ足りなくなる」4GBというメモリ量は「足りない」ということは揺らがない。

そして、使用するメモリというのは「何を」するかで話が大きく変わってくる。 まずChromiumやChromeを使っている時点で使い方としては重いわけだから、「ウェブブラウジングをする」というのを前提に話は進められない。 そもそも「これが当たり前」に言っている人は想像力も経験も足りないし、可能性を追求したり工夫したり想像したりしない人はエンジニアに向いてすらいない。

私がやっている中ではメモリを軽くするのが難しいのはホスト間接続テストである。 かなり多くのVMを接続する必要があることから、極限まで軽くしてもかなりのメモリが必要になる。 だが、少ないホスト数でテストする、ホストそのものを極限まで軽くする、という手段はとれるので20ホスト4GBとかで動作しているが。

もっと厳しいのは利用方法がそもそも制限されている場合である。

もっとも致命的な制限は「Windows 10を使う」だと思う。 最近のWindowsのリソースマネジメントは私には理解しがたい。 いくら性能を積んでもエクスペリエンスが改善しないのだ。Windows 7の頃は「リソースが有り余っているのに全然活用しない」という問題だったが、今はWindowsシステム側でリソースを食いつぶしてしまう。 40コア128GBのシステム(ディスクはサムスン製NVMe SSD)を以てしても「フォアグラウンドプロセスがバックグラウンドプロセスに邪魔されてスリップする」という不毛極まりない事態を起こす。 「馬鹿じゃないの!?」と大声で叫びたくなる。

なにをしてもとにかく無駄な処理が多いのだ。単純なプログラム起動時間も、かなり遅い部類に入るLinuxと比べても果てしなく遅い。

Windowsで重い作業をすることがなく、Windowsで8GBを使い切るのをみたことは一度もないが(少なくともシステムモニター上では)、Windowsの挙動なら必要のないメモリを食いつぶしてもおかしくはない、と思う。 もっとも、このマシン(40コアXeon)でもメモリを使い切る以前に「プロセスの起動待ち、その間他の作業は阻害される」みたいなことが頻繁にあるので、叩き壊したくなるほどエクスペリエンスが悪いし、メモリが増えたところで作業効率が上がるとは到底思えなかった。 それが気にならずメモリの容量を問題にしている人は、スマホを平気で使っているんだろうな、と思う。1

もちろん、Windowsはエクスペリエンスが悪すぎるから開きっぱなしにしている、という可能性もあるが。ただ、Windows10はウィンドウスイッチングも結構遅い。 (ビデオカードももちろん良いものを使っているのだが)

また、メモリを食いつぶすことで有名なアプリケーションと言えばEclipseである。 Eclipseを使うと一気にメモリ8GBでは怪しい、という事態になる。 これは今どき使わなければいいとか、果てはそもそもJavaを使わなければいいとかいう話にもなるのだが、Eclipseを強要されるケースは普通にあるようなので、こういう場合はやはり状況が変わってくる。

ただ、例えばGitの操作でメモリが128GBもあれば押し切ることのできる通常はできない操作というのもあったりするのだが、「メモリ8GBじゃ力押しできないから」というのはさすがに頭が悪い。 それは方法を考えるべきだ。実際、メモリ8GBだと重めのソフトウェアはYaourtのデフォルト設定でAURからのビルドはできないのだが、それは普通に実ディスクを使ってもらうようにすれば解決する。潤沢なときに許される力技ができないことに文句をつけるのは筋合いではない。

しかし、基本的には労働者にとっては必ずしも支給されるPCの性能というのは重要ではないと思う。 個人の裁量で他のマシンが使えるとなると結果的に労働者に対して負担を強いることになるため、非常に不適正といえるけれど、皆が同じマシンを使うのであればそれは統一された前提条件である。 コンピュータの性能は生産性とできることへの制限だから、業務効率やビジネス展開を制限することになるのだけど、それは労働者にとってはストレスだろうけれども、その時間でできることをすれば良いわけで、その問題に向き合う必要がない。その問題に向き合うべきは経営者だからだし、現に存在する「性能の低い(あるいは制限の厳しい)コンピュータで開発したくないから出ていく」というエンジニアのことを考えれば「人材の流出」という問題でもあり、それもまた経営者が向き合うべき問題である。

どのようなコンピュータを支給するかは経営戦略への影響も大きく、労働者側から不満を言うのはもちろん自由だが、その是非を断じるのはかなり難しい。 そして、それが「本当に不足なのか」あるいは「スキルでカバーできないエンジニアの戯言」なのかという点も、どのような条件に基づいているのかわからなければなんともいえないので十把一絡げに言えるものではない。

グレーディングの問題

コンピュータの性能が「上下」や「優劣」に使われる、という問題は、まぁわからなくはない。 というか、実際に私が思い描いている「会社経営像」でも「何をする人か」そして「どのような方法でする人か」「どのくらいのスキルがあるか」によって(さらにいえばもっと様々細かなことまで含めて)「個別に選定する」ことを想定している。 もちろん、これは顔の見える範囲でしかできない方法だが、コンピュータのグレードが揃っていないことは私はそれほど問題だとは思わない。

そもそも、メモリやCPUを「使う技術」と「使わない技術」はそれぞれ別にある。 私が使っているようなコンピュータは一般的なパソコンとは比較にならないほどリソースがあるし、これを単に「快適」などということで終わらせず、しっかりそのリソースを活用できるようになるにはそれなりにスキルがいる。 同時に、非常に性能の限られたマシンを最大限に活躍させるのにもスキルがいる。

だから「欲しい」で最大限与えるのは不毛なのだけれど、特別な理由がなければ特別な使い方をしない限り通常は不足しないように設定するのが好ましい。 そして、その「通常の使い方におけるリソース要求量」が「なにをどうやってしてるか」によってかなり差が出るのだ。

だから、その違いによって異なる性能のコンピュータを設定するのは悪くないだろうと思う。

だが、そこに変な要素が加わるのはさすがにまずい。

例えば、グレードの上下が地位の上下に比例するようにするとか。 これはもう、柔軟な更新ができず、まとめて更新なんてなったらすさまじい費用と税金がかかる最悪なパターンだと言っていい。

それから、「エンジニアよりもバックオフィスが下」というのもだ。 どちらかといえば日本のITはMS Officeに依存しているような面があり、効率がよくないMS Officeで、無駄に巨大なExcelシートを開くというようなことも割と珍しくないだろう。 そう考えると、「メモリ使用量が8GBを越える普通な使い方」は事務方のほうが想定しやすいほどだ。

現実的には

4GBというのは相当に厳しい制約だと思う。 普通に使えなくはないけれども、普通の人が普通に使える、にはならない。 経営者側からみれば、そこまでケチって生産性を下げることはメリットがないだろう。従業員が優秀か否かによらず4GBメモリのマシンを採用したならば、せっかくの人員を無駄遣いすることになるのはほぼ間違いないだろう。

8GBか16GBかということはやや難しい。 16GBあれば安心だとは思うが、ラップトップだと簡単に16GBを選択できるモデルは少なく、ハイエンド構成を要求されることが多いのが2018年の事情だ。 だから、「無難な線」という意味ではデスクトップでは16GB、ラップトップでは8GBになると思う。

デスクトップの場合8GBと16GBの金額差は割と小さいことが多く、ちゃんと選べば全体での価格差もあまりない場合が多い。そもそも、調達先はその程度の自由度をもって選択できるところと付き合ったほうがいいだろう (DELLとhpは大変無難な調達先として有名である。DELLはベンダー経由でも入りやすい)。

ラップトップまで16GBを投入するか…ということには著しい疑問があるのだが、会社支給のPCとしてはデスクトップを主軸として16GBにして、必要な場合に限りラップトップを8GBで追加支給するというのが無難なのではないかと思う。

「16GBが必要になる条件なんて限定的だから必要ない」という考え方は避けたほうがいいと思う。経営者ならば、労働者にとって争点になることを余計に作り出すべきではないように思うのだ。 8GBで不足することは稀だが、それを不満に思う人が少なくないし、実際に条件によっては不足するのだから差が小さいのならそこまでケチるよりは16GBを支給するほうが良い経営判断なのではないか。

サイボウズがやっているような32GBだが、私は過剰だと思う。 凄腕も揃うサイボウズで統一するという意味では別に構わないだろうけど、「サイボウズがやってるんだから32GBにすべき!」みたいなのは無視して良い意見だと思う。 4GBに留まっていた時代が異様に長かったが、8GBに移行してからも16GBへの進展はなかなかない。 採用されているメモリ容量は増加がかなり鈍っているのだが、実際のところ16GBを越えると一般ユーザーが活用するのはとても困難なので、10GbEが普及しないのと同じような感じで普及していかないのだと思う。 実際、私もデスクトップユースで16GBを超過することはかなり稀である。以前はあったのだが(使っていると20GBちょっと使っているという時期があった。特にMageiaを使っている時に)、現在は8GBにも到達していないことのほうが多い。

ちなみに、実際のところラップトップで作業しているときは画面スペースがないことから多くのアプリケーションによる並行作業をすることは少なく、また非常に大きなデータを扱うこともないことから8GBで不足気味になることもあまりない (もちろん、これは私が8GBしかメモリがないことを前提として負担をかけないようにしているからだが)。 一方、マルチディスプレイや大型高解像度ディスプレイ、さらには高速ストレージなどを採用して全体的に性能が向上するとマルチタスク性能も上がっていくためそれに伴って必要なメモリ量が増えて8GBを越える傾向がある。

そのため、コンピュータの固定資産としての価値が設定された3年以内に16GBメモリが「不十分な量」になることは考えがたいし、一般的なサポート上限である5年以内でも可能性は相当低いと思う。 だから余程特別な理由がなければ16GBあれば良いだろう。 あればあったで快適な状況や、できることもあるのだが、それは限定的だろうから支給PCの標準とする動機としてはとても弱い。

ハッカー(あるいはワナビー)が個人所有するPCであれば現状16GBしか使っていないとしてもよりメモリを必要とするテクニックを試すためにもより大きなメモリを積んでおいたほうがよかろうとは思うけれど。


  1. 私のスマートフォンはSnapdragon835搭載機だが、Wi-Fi使っててもあまりにおそすぎる。だから私はスマートフォンを必要がなければ触らない。 UXとしては、操作した結果が0.3秒以内に得られないのは失格だ、というのが私の設計方針である。 これは、「遅い」と感じる平均閾値に基づく。

Baloo File Extractorの大暴走

顛末

BalooはKDE5のファイルインデックス機能。 かなり性質は違うものの、部分的に見ればKDE4のNepomukを置き換える機能だと私は見ている。

先日、突然デスクトップが非常に重くなった。操作に対して数秒反応しないということを繰り返す。 私はConkyで常に状態を見ているのだが、Baloo File ExtractorがCPUを2.5%(=ロード1.0)使用しており、 IOも非常に高い。しかし、止まるほどではない気がするのだけど…と思い、嫌な予感がしてjournalctlしてみたら

11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file_extractor[2677]: qt5ct: using qt5ct plugin
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file_extractor[2677]: inotify_add_watch(/home/haruka/.config/fcitx/dbus) failed: (No space left on device)
11月 19 08:29:06 hydrangea baloo_file_extractor[2677]: inotify_add_watch(/home/haruka/.config/fcitx/dbus/4b235cc9521d448a9769a6f507904e37-0) failed: (No space left on device)
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file_extractor[2677]: QFileSystemWatcher::removePaths: list is empty
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file_extractor[2677]: QFileSystemWatcher::removePaths: list is empty
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.
11月 19 08:29:06 hydrangea baloo_file[2401]: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored.

地獄だった。 要はBalooがinotifyを食い尽くしてしまっていて、カーネルレベルでのエラーを(他を巻き込みつつ)無限に繰り返している、と。

というわけでBalooを止める。完全に。

$ balooctl disable
$ rm -rf .local/share/baloo
$ systemctl reboot

インテグレーテッドシームレスUXの代償

最近はOSが統合的な環境を提供するというのはひとつの流れになっていると思う。 やり始めたのはAppleだと思うけど、ユーザーの囲い込み勝負になっていて、WindowsだってなにかしようとすればWindowsのソフトウェアが自動的に起動する。 そのインターフェイスにもCortanaを使わせようとするし、各コンポーネントが密結合し、「全体でひとつ」に見せようとしてくる。

これが良いことなのかどうかは、ちょっと私には判断しかねる。 少なくとも理想的な挙動を考えればシームレスで統合されているのは美しいことだ。 だが、現実はそうはいかない。気に入らないソフトウェアや気に入らない挙動、そしてもっと好きなソフトウェアというのはどうしたってあらわれるものだから。 KDEが統合的かつ多角的に機能を提供してくれることは、私は好ましいことだと思っているが、ではそれに満足しているかというと、実際のところKDEPIMですら「余計なもの」だと感じている。KDE TelepathyではなくPidginを使っているし、KMailでなくClaws Mailを使っているし、Akonadiに至ってはいらないとすら思っている。

そして何より気持ちわるい。 AppleやMicrosoftやGoogleが統合的に機能を提供しようとするのは、ユーザーのUXのためではないし、単なる囲い込みのためでもない。 ユーザーの情報を集約し入手するためだ。 FacebookがなんでもかんでもFacebookを経由して利用させ、かつFacebookを常に開いておくように要求するのもそのためだ。 そういう意図を持っているのがわかっているのに、情報を集める機能があるというのは、私はすごく気持ち悪いと思うのだ。

KDEコミュニティはそのようなことはないだろう。なんといっても、情報を集約したところでその使い途がない、というかそもそもそんなサーバーがない。 サーバーがあったところで、ではそのデータは誰の所有物かという問題になる。 だからKDEに情報収集機能があってもそれほど問題はない…はずだが、それでも私はNepomukも気持ちわるいと感じていたし、Balooもそんなに歓迎していない。

そもそも、私の感覚からいえば、ファイルインデックス系の機能というのは無駄なコストだ。

基本的にファイルは属性に応じてちゃんとヒエラルキーを持って管理しているし、「フォルダをまたいで特定の条件でファイルを抽出したい」というケースはかなり稀だ。 もちろん、全く役に立たないとは言わない。その稀なケースでは役に立つわけだから。

だが、支払うコストがそれに見合ったものではない。 基本的にファイルインデックス系の機能は常に非常に多くのアクセスを行うし、CPU時間も長い。 つまり、ファイルインデックス機能が機能するために必要とするIO及びCPUのコストは極めて高いのだ。

ご存知の通り、Windows Updateは「Windows Updateをするべき余地がない」ことが確定しない限り非常に重い動作になる。 どれほど高性能なコンピュータを使っていても、ほぼ使い物にならない(マウスカーソルも止まるし、メニューも開けない、文字入力もひどいラグが発生する)状態になる。 常にWindowsを立ち上げっぱなしの人であればそれほど気にならないだろうが、Windowsをそれほど起動しない人にとっては、Windowsは常に操作をうけつけない印象になる。 これはアップデートのための話になるが、もちろんアップデートのためにこのようなアクセスを行うことは優れたデザインではない。

このような、操作を明らかに妨げ、コンピュータが使い物にならなくなるような、利用可能な時間が制限されるような、ディスクデバイスの寿命を縮めるような、コンピュータが著しくストレスを生じる性能であるかのように思わせるようなコストを払ってまで必要な機能ではない、と私は思うのだ。

KDEに関してはNepomukでも同じようなことを経験したはずだ。CPUを食いつぶし、IOを食いつぶし、メモリを食いつぶしてコンピュータが使いものにならず、どれほど崇高な理想を掲げたところでコンピュータが使いものにならなくなればそれは意味がないということを思い知ったはずだ。 Nepomukは結局ほとんどのプログラムに利用されることなく終わったし、KDE5には継承されなかった。 にもかかわらずBalooを採用した。いや、Nepomukでの失敗を踏まえて改善したものを投入したのかもしれないが、そもそもNepomukがなぜ失敗したのかということを理解していない、結局わかっていない。 実際のところBalooについて調べると「お前を消す方法」で溢れてしまうのがその証左だろう。

「優れたUXはあれこれお節介を焼くことではなく、余計なことは何もしないことである」ということに、 一体いつ気がつくのだろうか。

Libreofficeが超絶重くなった

Libreofficeがドキュメントを開くとものすごく重くなった。だいたいフリーズというレベルである。

どうもglibとの組み合わせによるようで、今年の頭くらいには発生していた問題だったようだ。 私の環境ではいままで顕在化してこなかった。

CPUが2.50%で張り付いている。 私のマシンは40コアなので、要はコア占有状態ということだろう。

glibの問題ということでUIテーマを変更すれば解決するようだ。 具体的には$SAL_USE_VCLPLUGIN環境変数により使用するUIエンジンを強制する。 選択肢は優先度順に

  1. gtk3
  2. gtk
  3. gtk3_kde5
  4. qt5
  5. kde4
  6. gen

であるようだ。

で、glibの問題なので要はデフォルトでgtk3が使われてしまうけれど、gtk3を使わせなければ良い、と。

私の環境はそもそもKDE Plasmaベース (デスクトップはCinnamon) なので、KDEを使わせたいのだが、 現状Arch Linuxのlibreofficeはビルド時に--enable-qt5していないため、qt5が使えない。 もちろん、kde4は今や使えない。gtk3_kde5してしまうと結局同じ問題が発生する。 (gtk3との違いはファイルダイアログを表示すればわかるだろう)

そこで、SAL_USE_VCL_PLUGIN=gtk libreofficeとすれば正常に動作する。gtkでなくgenでも良い。

以前から割とgtk3テーマのlibreofficeは重かったので、もしかしたら常に強制しても良いのかもしれない。

ここらへんの情報はArchwikiでも古くて間違っているので困る。記述も雑だ。

Libreofficeは滅多に使わないのだが、請求書とか発注書とかはLibreofficeで書いている。 MS Officeと同程度にはやっぱりストレスがたまる。

この手のソフトウェアとしてLibreofficeよりも良い選択は恐らくない。AbiWordもCalligra Officeも機能的あるいは実用的に遠く及ばない。 にしても、やっぱりLibreofficeできれば使いたくないところだ。 紙面ベースのレイアウトをする場合はHTMLもそんなに快適ではないのでやむなく使ってはいるが。 (この手の書類は見た目だけの問題で意味的に整理する必要は全くないし)

とりあえずこうしてUIエンジンをかえられることを知っておくと今後もなにかの役に立つかもしれない。

McAfeeの「パソコン動作を軽くする対策8選」 のおはなし

スラドで記事になっていたので 少し触れてみようと思う。

結論としては、

  • McAfeeの記事は「懐かしい」
  • 批判している記事のほうは知識があまりに足りないのでひどいものだ

内容的にはWindows 98の頃に常識的tipsと言われていたものなので、検証もしないまままだいい続けている人がいるのか…という感じではある。

個別に

常駐アプリケーションの無効化

これは確実に効果がある。 だが、現在(Windows 10)は多くのケースにおいて「効果のある変更はできない」のが実情だ。

批判記事のほうではメモリの問題と考えているようだけれど、常駐アプリケーションに関してはメモリの問題はかなり小さい。 なぜならば、メモリが常駐アプリケーションのために不足するほど少ないことは稀だし(常駐アプリケーションの中身次第だけども)、メモリのアクセス速度は比較的速いため速度低下に通じる条件は割と狭い。

常駐アプリケーションが重くなる最大の理由は、「遅いリソースに対するアクセス」であり、一番はディスクアクセスである。 ほんのわずかでもディスクアクセスが入れば全体的に結構遅くなる。 ディスクからインデックスを作るようなタイプのプロセスは走っているときにエクスペリエンスを著しく落とすことがあるので、こういうのは切ると効果が大きい。

ネットワークアクセスも場合によっては重い。直接接続されているインターフェイスが高速ならいいのだが、不安定なWi-Fiなどにつながっているときの挙動が全体の動作に影響を及ぼす場合も(だいぶ稀だが)ある。 ただ、このような挙動を示すものはWindowsでは少ない。スマートフォンの場合全体の中でネットワークに依存する度合いが高いこともあってネットワークアクセスするバックグラウンドプロセスの存在は全体のエクスペリエンスに大きな影響を及ぼす。 これはWindowsでも大きな通信を常時している場合や低速なインターネット接続である場合は同様の問題があるだろう。

スリープ、あるいはブロックしないタイプのプロセスの場合は定期的にCPUを要求することになり、プロセススケジューラ的に負担になる。 さらにいえば、そこで負担のかかる処理をしているとCPU時間的にも重くなる。 これは「重い処理をするプロセスは」と捉えるかもしれないが、そんなことはない。Windowsにはforkはないけれど、例えばLinuxの場合はジョブスケジューラによってシェルスクリプトを定期実行しておくようにしたりすると、シェルスクリプトがコストの高いfork(2)を定期的に発行することになるので、結構重くなる。

これらの問題が体感的に重くなるかどうかはかなり様々な条件によって変わるのだが、そもそも記事自体が「重いと感じている」ことを前提として、「どのように重いと感じているかの究明はしない」というスタンスで「やってみれば軽くなるかもしれない」という記事を書いているのだから間違ってはいない。

容量の大きいファイルの削除、移動

「データ量が増えるとアクセス速度が遅くなる」のはそもそもHDDの物理的特性に依存している。 HDDでデータが増えるとデータが物理的に遠くなるのでかなり遅くなる。 ランダムアクセス速度はさらに遅くなる。

HDDはコンピュータの中で現在多くの場合最も遅いデバイスなので、これが遅くなるとCPUから見るととんでもなく低速化したことになる。

実際に記事はハードディスクドライブ、と明示されているので正しい。

これはファイルシステムとディスクデバイスの問題とは別である。

使っていないアプリケーションの削除

様々なリスクを低減することにはなるが、エクスペリエンスへの直接的な影響は基本的にない。

ただし、バックグラウンドでの動作を抑制し、ディスク要領を空けるという意味はあるので前2項と同じ話だろう。

デフラグをかける

ハードディスクでは物理的な移動量を減らすことにより効果がある。 ただし、昔ほど劇的な効果はない。 ディスクへのダメージを考えると「余程のことがない限りしないほうが良い」というのが近年の考え方だ。

ディスクのクリーンナップをする

これも空き要領を増やすのとだいたい同じなのだが、他にも効果がある。

キャッシュ自体がインデックス対象になるケースと、キャッシュが増えることでオーダーも増えるケースだ。 だが、そんなクソ実装なソフトウェアをイマドキ使っている人はあまりいないと思う。

ブラウザのキャッシュをクリアする

これは恐らく間違っている。

昔のInternet Explorerはそもそもキャッシュをプリロードする仕組みだったし、キャッシュヒットの計算量もキャッシュ量によって増加するようになっていた。

けれど、今はだいたいsqliteだったりするので、キャッシュ量がパフォーマンスに与える影響というのは無視できるレベルである。 それよりはキャッシュがないことによって発生するネットワークアクセスに伴うパフォーマンスへの悪影響のほうがずっと大きいだろう。

ちょっとハードディスクに対する容量管理に対して神経質すぎるのではないだろうか。

ディスク容量という意味ではブラウザキャッシュはものすごいサイズになることが多いので、むしろ容量の少ないSSDのほうが消したいかもしれない。

視覚オプション(アニメーション表示)の解除

批判のほうでメモリ云々言っているけれど、Windowsのアニメーションのロードは別にアニメーションを行うときに読まれるわけではないので、メモリに対する影響はない。

しかしこれはパフォーマンス上は効果がない。 今Windowsのアニメーションはハードウェアアクセラレーションによって実行されるようになっており、CPUに対する負担が(ほぼ、あるいは全く)ない。 ハードウェアアクセラレーションのできないPC構成は現代のものとはとても言えないだろう。

ただ、エクスペリエンスという点に限って言えば意味がないとも言い切れない。 なぜならば、アニメーションには時間がかかるので、「待ち時間が遅い=重い」と感じるかもしれないからだ。

記事中では

視覚効果を出すための動作はパソコンのパフォーマンス・動作スピードを落とす原因にもなります。

とあるが、動作スピードは落ちてもパフォーマンスは落ちない。

再起動を行う

再起動を行うことで問題が解消されるケースについて説明しまう。

昔定期的に再起動が必要だったのはメモリリークによるものである。 メモリリークとはメモリに領域を確保して開放しないままプロセスが終了してしまうことによりメモリを占有したままとなり、メモリの空きを減らしていってしまう問題だ。

だが、現在は処理系やOSの改善もあり、このようなケースは比較的少ない。

どちらかといえば終わるべきプロセスが終わらない、本来ひとつしか起動しないはずのプロセスが複数起動してしまう、ロックファイルが消えない、FIFOが多重に書かれて上書きされる、起動処理に失敗する、変数がバグって変なループにおちる、待ち合わせタイミングがおかしくなってブロックしつづける、マルチスレッドのプログラムが一部スレッドだけ落ちる、といった異常な状態が解消できる(ファイル残りなどは解消できない場合もあるが)。

だが、このような問題はごく最近、劇的に少なくなった。 以前はデスクトップユースで数日に渡って連続使用するというのは結構難しかったのだが、現在はWindowsでもLinuxでも1ヶ月程度の連続稼働はなんということもなくこなしてしまう。 こうした不整合による問題は非常に起こりにくくなったのだ。

だから、「不快なエクスペリエンスを解消するために再起動」というのは網羅的に書けば出てくるけれど、あまり重要ではないと思う。

ただし、書くこと自体には問題ないとも思う。 モデルライフで意識的に再起動したことが一度もない、というユーザーを私は結構知っているし、そこまでになると再起動することで解消することもままあるし、初心者向けに書かれていることから再起動という知識がないケースも想定されるのであっていいと思う。

以上を終えて

放っておいてもよかったような内容だが、なんとなく批判のほうが正しく、McAfeeが悪いような空気になっていたので書いてみた。

それぞれがどのような知識、どのような思考で書いたのかは容易に想像できる書き方であったが、 McAfeeのほうは本当に初心者を想定して、理解を度外視して手順だけを並べたのだろう。 だから意味的には同じものも書かれている。

しかし、私はどちらに対してもどうこう言いたいのではなく、 どちらかと言えばMcAfeeの書いていることが「懐かしいねぇ、2000年ごろは至るところでこんなことが書かれていたねぇ」と微笑ましく読むところだろう。

ERINA the emotional AIのコンポーネントモデル

論文前に公開するERINAの解説・紹介、第二段である。 今回はERINAがどのようなコンポーネント設計から成り立っているかを紹介する。

ERINAは他のAIと比べ、かなり複雑で大規模なプログラムとなっている。 多角的なエミュレーションのために処理は泥臭く複雑だ。 さらに、非常に長期に渡って開発されているために、開発言語がかなり多く、開発時期もバラバラのコンポーネントがごった煮のようになっている。 そもそもERINAの目標は果てしなく遠いものであり、その開発の事前予測は事実上不可能である。このようなプログラムは非常に高い可能性で混沌の中で終焉を迎える。

だが、実際はERINAはそのような失敗に至るプロダクトのような特徴を持ちながら、うまく調和がとれ、良い結果をもたらしている。 古いコンポーネントの改修は不可能に近いほど困難だが、新規開発や古いコンポーネントの置換えはそれほど難しくない。

これは全体を通じる設計の効果によるところが非常に大きい。 個々のコンポーネントは追加することも削除することもできるし、設計に基づく約束事さえ守れば全体の設計は個々のコンポーネントの設計には立ち入らない。 これはいわゆるカプセル化やダックタイピングに通じる考え方で疎結合しているのである。

このような設計には私はふたつの物事からインスピレーションを得た。 ひとつはUnixのツールボックスであり、もうひとつは生物的モデルである。 生物においてそれぞれの要素が適切に自分の役割だけをこなすことにより、結果的に全体が調和して生命を形成する。だが、例え一部の要素が機能しなかったとしてもそれが直ちに生命を損失することにはつながらない。ERINAのような予測も把握もできない、変化しつづけるものにはこのような設計が適しているように思えたのだ。

なお、ERINA/Surtrのコンポーネントの命名だが、北欧神話に関するものと脳神経に関するものを使っている。 だが、北欧神話の用語の使い方としてはやや間違っているし、脳神経に関する用語に関しては多分大いに間違っている。 論文を書く時に問題になりそうでちょっと困っているのだが、そういうふうに名前をつけてしまったてので大目に見ていただければと思う。

さらに内部的に使っている用語としては

  • ヴァルキリー = データを収集、分析、登録するワーカーのこと (実際はプログラム自体よりワーカーを指していうが、プログラム名称にも一応入っている)
  • エインヘリアル = 収集対象になっているデータのこと
  • ヴァルハラ = エインヘリアルを解析したデータベース(somaデータベース)のこと
  • アスガルド = データベースやERINAインスタンスなど、「こっち側」
  • ミッドガルド = ERINAがコミュニケーションを取る相手や、取得可能 or 未取得な情報などの「あっち側」

という扱いである。ゲームとかファンタジー小説とかが好きな人ならなんとなく伝わるかもしれないが、そうでないと全くわからないだろう。 これについては、「短い言葉で端的に概念を表すことができるようになったことは素晴らしいが、よく綴り間違えて痛い目を見る」という感じである。 脳神経に関する言葉を採用したのはその問題を解消するためだったが、結果「概念が若干似ているがために用法として間違っているように感じられるものになってしまい、口外するのが恥ずかしい」という別の問題を発生してしまった。

orbital design

orbital designは処理対象をキューとして生成し、複数のワーカーが順に処理を行っていく独自のモデルデザイン。

ワーカーは基本的にはジョブスケジューラによって生成される。 この起動時にキューも生成される。 このことから場合によっては生成されたワーカーがキューを消化する前に次のキューとワーカーが生成されることになるが、構わず複数サイクルが同時に回るようになっている。

つまり、処理対象はキューが生成されるときに確定されている。 この瞬間から状態が変更されたとしても影響を受けない。 これを実現する手っ取り早い方法は「スナップショットを取って、スナップショット上のデータを対象にする」である。

orbital designによりコンポーネント全体で連続的処理を行う構造になっている。 完成、あるいは完了という概念がなく、それぞれのコンポーネントが自身が担う処理を最新の状態にアップデートしつづける。

これはアジャイル開発やPCDAサイクル(これはちょっと違うか?)と似たような考え方でもある。

ERINAは実装面では決して良いものではないのだが、それでもなんとか動作しているのはこれを含めたデザイン面が大きい。 それぞれのプログラムが独立してサイクルを回せるようになっているため、技術レベルや実装言語などによらずシンプルな約束事だけでコンポーネントを作り、使っていくことができる。 ずっとむかしに作られたPerl製コンポーネントが今も動作するのはこれが理由で、ERINAの実装言語がやたらに多い理由でもある。

基本的にデータの受け渡しが必要なときは標準入出力経由のテキストであると決まっている。 最近新しく登場した部分はYAMLになっているが、XMLだった時期もあるし、もっと独自の形式だったときもある。 ただ、基本的にコンポーネント種別ごとには受け渡しフォーマットも統一されている。 実際には変更されることもあるのだが、そのような場合は一世代ごとに形式を変換するフィルタがあり、これを世代数分経由することで統一を図っているものもある。

orbital designとこの規約どちらが先かというのは難しいところだが、決めたのは標準入出力経由というのが最初で、 コンポーネントを連動させると大変というのはかなり初期からあった問題なのでほとんど最初から独立してそれぞれが自分のことに専念できるように書かれていた。 その発展として最近採用されたのがorbital designというわけであり、初期は繰り返し直列的に処理していくシェルスクリプトだった。 明確にorbital designというコンセプトを決めたのは2015年である。ただ、それらしきことはそれ以前からしていた。

orbital designのメリットを簡単にいうと、AとBというふたつのデータベースがあり、それぞれが解析によって得られた結果を書き込み、その解析はAのためにB、BのためにAが使われるとき、AとB両方のデータベースを連続的に同時に更新したとしても時間と共に精度が向上する、ということにある。 ERINAの場合は話はそこまで単純ではないが、相互に必要とされるデータベースの更新を並列かつ連続的に行うためのデザインとしいうことには変わりない。

orbital designは結構幅広くメリットがあり、例えば計算することそのものは独立しているため入出力の問題さえなんとかなれば非常にスケールしやすく、コア数やマシン数で稼ぎやすい。 特にERINAは通しで処理した場合データ量増加に対して処理量は指数的増加するようなモデルであるため、非同期かつ連続的に更新していけることは必須である。

このデザインは設計・採用するのが容易で、見通しがよくなり、実装も楽で、停止もしやすい、といったメリットがあるので結構有用なのではないかと考えている。

入力

Ninja Valkyrie

Ninja Valkyrieはデータの収集を担う。

プログラム的にはそれぞれのメディアに合わせたものが存在する。 その詳細は秘密であるが、 インターネット(特にウェブ)のみからデータを収集しているわけではない という点は強調しておこう。

基本的にはERINA(というかSurtr)にとっては情報のことをエインヘリアルとして扱うことになっている。 私は北欧神話にそこまで精通しているわけではないので、斥候を担う者にちゃんと名前があったりするのかもしれないが、それは知らないためNinja Valkyrieと名付けられている。 もちろん、斥候だからNinjaだ。

Ninja Valkyrieはあくまでデータをデータとして取ってくるところまでを担う。

Guardian Valkyrie

Guardian Valkyrieはデータのデータベースへの登録を担う。 大部分がファイルシステムベースのデータベースになっているため、Guardian Valkyrieの出番は非常に少ない。

最も大きいのは動画専用のフラグメントオブジェクトファイルシステム(Surtrコンポーネントの一部として専用に開発されているもの)に動画を切り刻んで登録することである。 この処理に関してはそれ以上解析する余地がないため、Knight Valkyrieによる処理が行われない。

ただし、この方法はあまりうまく言っているとはいえない。 動画の解析の難しさもさることながら、やはり本質的にデータが失われることが重大すぎる。 もちろん、この方法は「収集する動画データを動画として保持しておくだけのディスクスペースがない」ことに由来するのであり、あまり実用的な期待は持てない状態だ。

Knight Valkyrieと両立されている関係にあるGurdian Valkyrie最大の仕事はファイルインデックス(取得日時や更新日時の情報を持ったデータベース)の生成であり、これはKnight Valkyrieがキューを生成するために必要になる。

Guardian Valkyrieは基本的にはNinja Valkyrieから呼ばれる。 この中には現在の形式に合わないエインヘリアルを連れてくるNinja Valkyrieを現在のフォーマットに合わせる処理を含んでいる。 このためにGuardian Valkyrieの呼び出しコマンドはラッパーとなっており、呼び出し形式に合わせて別のGuardian Valkyrieに移譲する方式。 もし現在望まれる形でデータを保存するNinja Valkyrieから呼び出された場合はGuardian Valkyrieはなにもしない。

Knight Valkyrie

エインヘリアルたるデータをヴァルハラたるデータベースに登録するのがKnight Valkyrieである。

このデータベースに登録されるのはインテリジェンスが直接扱うことのできる細分化した情報の断片である(somaと呼んでいる)。 Guardian Valkyrieが取得したデータ全体をデータベースに登録するのに対し、Knight Valkyrieはデータの解釈や分解などを行う。

Knight Valkyrieもひとつのデータフォーマットに対して一種類だけしか存在しないわけではない。 特に会話文テキストを解釈するKnight Valkyrieに至っては30種類以上に及ぶプログラムが存在する (そしてそれはそれぞれ異なる言語で書かれていたりもする)。

ひとつのデータに対してそれぞれのvalkyrieがそれぞれの解釈によってデータを登録することはERINAのデザインにとって重要なものになっている。 これは特定の考え方や特定の視点、特に常識や前提にとらわれることなく発見を続けていくためには例え思い違いで役に立たないようなものであってもそれぞれのルールで解釈・解析することが必要なのだ。

Knight Valkyrieはさらに分解した情報を元に「盤面」を作るという処理も行う。 実際にsomaとして扱われるのはこちらのほうで、分解した内容は盤面に対してタグ付けしたような状態になる。 分解した内容は検索に使われるほか、次段のシナプス形成においても必要となる。

これがKnight Valkyrie単体で担っていることに違和感があるかもしれないが、実際はこのあたりを分けて話すのは難しい。 なぜならば、盤面を構成するのは「分解した要素の構成」だからであり、要素の集合は盤面のIDとして機能する。 おおよそこのデータベースはキーバリューストアのようになっているのだが、要素の集合はキーとしても値としても動作する。

そして盤面側は複数のデータベースがレイヤー状になっており、このほかに要素に基づく統計的データベースが複数存在する。

Knight Valkyrieの動作は最も実装が難しいもので、「思考とはなにか」「情報は何を持っているか」ということを決定づけることになる。

Connexon

Connexonは盤面(soma)に対して接続可能な盤面を登録する。 ちなみに、接続可能な盤面を表すキー名はsynapseになっている。

この処理自体は単純なものであり、入力過程にあるものでは唯一稼働している実装が1種類しかない。 ただし処理が単純だからといって実装が簡単なわけではない。Connexonが簡単なのは、「どのような要素に分解し、この要素はどのような意味を持ちうるか」という設計をKnight Valkyrieの時点で行う必要があるために、Connexonによって新規に設計する必要がないということに過ぎない。

また、処理は単純だが、接続可能なsomaを探索するために全somaをあたる必要があり、しかもsynapseが更新されると接続可能なsomaも更新されることになるため非常に長いループを回すタイプである。ERINAコンポーネントの中で最も長いCPU時間を求めるのがConnexonである。

そして処理量の関係上、現状Connexonは全てのsomaを巡回しない。Connexonのキュージェネレータが「Connexonが当該somaをいつ巡回したか」「somaがいつどれくらい探索されたか」という情報を元にキューを生成する。だからsynapseが長く更新されていないsoma、及び頻繁に参照されているsomaが優先順位高くキューに入ることになり、生成後一定時間経つとキューの状態に関係なくConnexonキューは終端を返す。

なお、私は解剖学・生物学の知識もそんなにないので、名前に対するツッコミはお控えいただきたい。 ただし、新しいネーミングのご提案はいつでも大歓迎である。

Neuron

NeuronはKnight Valkyrie及びConnexonとは別のフローでエインヘリアルを接待する。

これは主に語彙や知識に関する情報収集と接続を行うものであり、一般的なビッグデータ処理に近いものになっている。 Neuronによって処理されるデータは盤面を作られることはないのだが、そもそもKnight Valkyrieがこのデータベースを使う。

Neuronが作るデータベースは解析だけでなく生成側でも必要となる。

対話

Erina receptor

Erina receptorは入力された情報から盤面の探索を行うものである。

Erina receptorはまずKnight Valkyrieを使って受け取った要素を解析する。 そして、「与えられた要素」と「コンテキスト上キープしている要素」から得られる要素を、Erina context finderによって絞り込み、これによって残る要素を元にコンテキスト上のcurrent盤面のsynapseを探索する。

Erina receptorは探索されたsomaのIDとスコアを返す。 なお、somaは「発言」ではなく「状況における言動の要素」の盤面であるため、「無視する」といった行動もありえる。

Erina context finder

状況を推測するための調整用フィルタであり、アルゴリズムやデータベースを含めた完全手入力である。

これは、「前回の会話からこのメディアでこれくらいの時間が空いたら前回のコンテキストとの関連性を下げる」というような処理を行う。

これが調整用であるのは、そもそもKnight Valkyrie側に「応答時間の変動」のような要素を理解する処理が入っているからだ。 だから学習的にしきれない部分をフォローするためにあり、基本的にはこのプロセスのみが担っているものはないはずである。

だが、とても重要で、このフィルタがないといまいち自然な応答にならない。 「その話今する!?」みたいな不自然な感じが残ってしまうのだ。

Erina emotion engine (effector)

Erina emotion engineはかなり複雑な処理をするため複数コンポーネントに分かれているが、それらは直列に処理するためここでまとめて紹介する。 なお、Erina emotion engineはERINA固有のものであり、Surtrにはない。ERINAが単独で存在する意味は元はSurtr emotion engineと呼ばれていたこのコンポーネント群にある。

Erina emotion engineはneuronデータベースをかなり細かく読み込む。 これはキャラクターづくりにも関係している。

単純にErina receptorの結果から「それらしい振舞い」を導き出すことはできる。 だが、実際にはErinaは常に最善手を指すわけではない。 もし常にreceptorが最も高いスコアをつけたものを選ぶと「振舞いに全くゆらぎがない」「人物に一貫性がない」といった問題が出る。 これは非常に重要なポイントで、このような特徴に対しては人間はかなり敏感に反応し、不自然さを感じてしまう。

そのため、Erina emotion engineはまず「キャラクター性」というものを持つ。 これを実現するためにErinaインスタンスは自身に特化したキャラクターデータベースを使用する。 ERINAにとっての「学習」はこのキャラクターデータベースの更新にあると言っていい。

Erina emotion engineはまずキャラクターデータベースに基づいてreceptorが返したスコアを書き換える。 この機能のためにreceptorは複雑なスコアのつけ方をしている。

この処理にはコンテキストも使われる。 生活状態や感情状態という要素があり、これはシミュレーターのように計算・動作する。この部分はおおよそ(硬派な)シミュレーションゲームのような処理である。 このコンテキスト処理が「ゆらぎ」を担う。この処理のときに行動条件も出す。これは「返信をわざと遅らせる」といった処理のために使われる。

コンテキストの生成・更新もErina emotion engineの機能の一部であり、この情報はインスタンスデータベースに書く。

キャラクター性による再評価と出力の編成は近いものがある。 キャラクター性を評価した段階で意味的にはこのような振舞いをする、ということがわかっている。 「どのような心理状態か」「どのような行動か」ということは新たに定義しなくても要素の組み合わせで確定できる。 なにを発言するかという点で主旨はなにか、というのはsoma側にある。そのため「応答すべき内容が表現段階で意味的に間違う」ということはまずない。

その状況における意味的な言葉というのはKnight Valkyrieが集めている。 これは主には同じ要素構成になる言葉(綺麗な文章であるならば「文」)の共通要素を抜き出す方式である。

そしてneuronデータベースには発言の編成がある。 そもそもKnight ValkyrieもNeuronも共に「誰が誰に対して発言したか」という情報を取り扱うため、模倣するのは比較的簡単。 特定の組み合わせから見た一連の発言だけでは非常に表現に乏しくなってしまうため、なるべく類似の発言傾向をまとめるようになっている。

例え意味や心理を完全に模倣できていなくても、ある一定の傾向を持つ発言を元に、意味的にどのような発言をすればいいかということを外さないように組み上げるため「ちゃんと意味が通っていて会話が成り立つ」感覚が補助される。 実のところそもそもERINAは人間の身勝手な補完と錯覚を突くように作られているため、発言を精査すると意外とあやふやである。

別の角度から見ると、他が分析・理解・解明を追求しているのに対し、この出力部分だけ結果が出ることを重視した全く異なるアプローチになっている。 そうなっている理由は、「この部分だけがERINA固有のコンポーネントだから」である。データベースの利用方法として検索や検証といった機能はSurtr側にあり、ERINAは基本的にコミュニケーションの様態を模倣する方向であり、Surtrのコンポーネントとはアプローチが異なる。 現在の試行の範囲では理解など忠実な再現において自然なコミュニケーションを実現することはかなり遠そうだが、ERINAがそれを目指すことはない。 なぜならばERINAの意図、そして命名理由からも外れてしまうものであり、もしそれを目指すとしたらERINAとは別のAIとして開発することになるだろう。

アルゴリズムに踏み込んだ話はおいておくとして(なんとなく筆がそっちに走ってしまったが)、Erina emotion engineの手順としては

  1. キャラクターとコンテキストをロード
  2. コンテキストの解析と更新
  3. receptorの応答の受け取り
  4. キャラクターに基づいて結果を編集
  5. 応答に使用するsomaを決定
  6. somaとキャラクターに基づいてneuronデータベースを検索し応答語句を編成
  7. コンテキストを更新
  8. 結果を出力

となる。

コンテキストの更新をreceptorの応答を受け取るより前にも行っているのは、receptorが探索にコンテキストを使うため。

Erina controller

receptor, emotion engine, media frontendとのやりとりを仲介するコンポーネント。 一応、これがERINAのインスタンスプロセスになる。

なんのデータベースをロードするかはこのcontroller起動時点で決定する。 というよりも、インスタンス生成時に決定する必要があり、変更は難しい。変更してしまうと初期化されてしまう。

コンポーネントとのやりとり以外ではコンテキストデータベースとキャラクターデータベースの初期化処理を受け持っている。

Erina media frontend

入出力処理用レイヤー。

単に読み書きするための抽象化をしているのではなく、文字数、送信ペースなどの「自然なやりとりのスタイル」を定義するデータベースでもある。 ちなみに、これも学習ではなく手入力。

emotion engineが語句編成のときに使うものはこのレイヤーの種類分あるわけではなく、メディアタイプはごく少ない種類だけで、あとはちょっとした調整パラメータがあるだけ。 調整パラメータは「連続送信」「顔文字」「絵文字」「Unicode」「句読点」などなど。

例えば連続送信型とした場合、改行したりするよりも複数の発言に分けるようになり、文の構成が簡素になる。 あまり推敲していないような文章になりやすく、端的でかつ文単独では意味が伝わらないような発言を選択する。 連続送信型でない場合は、発言主旨を一度の発言にすべて含めるようになる。

(Manjaro Linux) KDE PlasmaでXFce4通知が使われる

先日のAdaptaのアップデートからManjaro XFce4からインストールした環境で使用しているKDE Plasma上で通知が黒背景黒文字になるという問題が発生していた。

KDE Plasmaの通知を設定しても全く改善されないためどうしたものかと非常に困っていたのだが、 よく見てみるとKDE Plasmaの通知ではなく、XFce4 Notifyになっていた。

そこでxfce4-notifydを止めたいと考えたのだが…

xfce4-notifydはsystemdユーザーユニットとして存在していて、/usr/lib以下にコマンド本体がある。 だからsystemctl --user stop xfce4-notifydで一応止まるように見える。 (場合によってはkillする必要がある)

ところが、ここでnotify-sendするとふたたび起き上がってきてしまう。

これを止めるジェントルな方法を模索したのだが、見つからなかったので、仕方なく/usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.serviceを削除(というか外へ移動)した。 これは恐らく意図以上の影響を及ぼすだろうが、とりあえず当面の問題は解消できた。

アプリケーションに固有のfonts.confを使用させる

意図

私はどうしても、どうしても!!! ウェブサイトが無意味にフォントを固定してくるのが気に入らない。

いくらでもいいフォントはあるのに、よりによってなぜMS PゴシックだのArialだのHerveticaだの気に食わないフォントを強制されなくてはいけないのか。

「MS Pゴシックはないんだからいいじゃん」と思うかもしれないが、それでは済まない。 「完全にMS Pゴシックに決め打ちしているもの」というのも世の中には存在するので(一番はMSWord文書)どうしてもMS Pゴシックはメトリック互換フォントを設定せざるをえないのだ。

Arialに関してはUI部品に本当に使っていて、はみだすケースが少なくないので、変更はより難しい。

そうでなくても指定されるのは気に入らない。 必要ないのではないか。 私としては読みやすいフォントを使いたいのだ。

最も望ましいのはユーザースタイルシートで上書きすることである。 だが、ご丁寧にどのサイトもbodypではなくスコアの高いところにフォント指定してくれやがるのでそうはいかない。滅びてしまえ。

幸いにも私の場合プロファイル切り替えプログラムを使っているのでそのブラウザで見るサイトというのは決まっている。 だから手っ取り早いのはサイトで指定されているフォントをoverrideすることである。

実際、

とかやっているのだが、やはり弊害が大きく、条件は限定したい。

意外とイケてないFontConfigの仕様

FontConfigって結構イケてるソフトウェアだと思っていたのだけれど、そうでもない。

設定にXMLを使っている時点で微妙だし、その文法はさらに微妙だが、 環境変数のような動的要素は全然使えない。

XDG_CONFIG_HOMEだけは理解するのだけど、そのロジックはinclude内のprefix="xdg"である。 このprefixdefault (/)かxdg ($XDG_CONFIG_HOME | ~/.config)のどちらかだけ。 かろうじて~は使えるのだが…

条件式も書けないし、アプリケーションごとの設定もできない。 とにかく自由度が低い。というか、設計がイケてない。

方法はいくつかある。

例えば、~/.application.font.conf.d/をincludeするようにしておいて、 これをシンボリックリンクとして切り替える、というような方法だ。 だが、これは優先度が高いところでincludeするほど影響が大きく、制約される。

ただし、この方法ではアプリケーションがFreeTypeをロードしたあとであればこのリンクを切ってもリンク先のディレクトリをホールドし続ける。FontConfigが再度シンボリックリンクを解決することはない。

だが、よりよいのは環境変数$FONTCONFIG_FILEを使う方法だ。 これによりカスタムのfonts.confを使わせることができる。

だが、これも罠が多い。

まず、ファイル向けの$FONTCONFIG_FILEとディレクトリ向けの$FONTCONFIG_PATHがあるのだが、$FONTCONFIG_PATHにしてもNN-XXXX.confをロードするわけではなく、単にそのディレクトリのfonts.confをロードするだけである。 しかも、どちらも複数指定はできない。

このふたつがある意味がないし、柔軟性が全くない。 やっぱりFontConfigがいまいちだ。

固有のfonts.confを使わせる

だいたいこんな感じである。

この設定ファイルにはしたいことだけ書けばいいわけではなく、/etc/fonts以下でやっているようなことが全て必要になる。 手っ取り早い方法としては

のように書いておくことだ (いや、多分/etc/fonts/conf.dをここで指定する必要はない)。 これで通常の設定ファイルがロードされる。

この設定ファイル内で書いた内容はincludeの前でも後でも優先され、overrideできる。 だから、この内容を基本として固有の内容を書き足せば良い。

ただし、効力は通常されるどの設定ファイルよりも強いので注意が必要。

この方法は汎用性があり、エディタでフォントを使い分けたいときにも有効に働く。 例えばsans-serifmonospaceのような抽象フォントを指定しておき、それをoverrideすれば良い。 arialhelvetica, MS Pゴシックなどをグローバルに置き換えることも避けられる。

Web browser profile chooser version 2.0

My browser profile chooserが従来はこのような余計なコマンドの実行に適していなかったので、特殊なことをしなくても実現できるように変更した。 これは、既に廃止されたブラウザの削除、設定ファイル指定オプションがなくなったMidoriの削除など懸案だった変更を多数含み、 従来とは互換性がない

従来の強引な手法が訂正されたため、設計も改善された。 これで例えば次のようにして任意のフォントプロファイルで起動できる。