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の削除など懸案だった変更を多数含み、 従来とは互換性がない

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

ウェブサイト全文検索システムの開発

開発経緯

NamazuやGroongaも試したのだが、いまひとつ望むものにはならなかったので、シンプルで美しい全文検索システムを書くことにした。

これは、第一にはGoogle検索に依存しているMimir Yokhamaの検索機能を自前で持つこと、 第二にはChienomiを含むWordPressのシステムの置換えである。

検索システムの開発自体はそれほど難しくないと思うのだが、どのように動作するのが望ましいかということを考えると非常に難しい。 Googleの検索システムは非常に高度なので、それに匹敵するものを作るのは難しいのだ。

だが、ここはPureBuilder Simplyにふさわしいシンプルなものを目指すことにする。

設計その1

とりあえず、grepを使えば話が早いのだが、HTMLだと余計な要素を含んだ検索になってしまう。 HTMLからタグを除去するのは難しくないが、どういうポリシーで除去するのか、いつどうやって除去するのか、などが難しい。

PureBuilder Simplyの構成から言えば、生成時に、Pandocで生成するのが望ましい。

$ pandoc index.md -t plain index.txt

だが、生成時に生成を全く無視してインデックスを生成するのはどうだろうか? そもそもPre pluginsはソースファイルを、Post Pluginsは生成したHTMLファイルを加工するものであるため、本来の目的から逸脱してしまう。 例えばPre Pluginsを使って

とかもできる。

ただ、今のところ検索対象になるようなソースファイルを加工するようなPre plguinsを使っていないため、別にこのようにする必要性はない。

設計その2

あとから処理するためのもの。 .indexes.rbm に基づいて処理を行う方式。

検索

いずれにせよここまでやってしまえば検索は簡単。 grepで検索できる状態なので、シンプルに検索可能。

AND検索の要領としては

ものすごく検索対象が多い場合は、検索対象そのものを絞り込んでいくほうがいいだろう。 だが、プロセス起動回数が増えることを考えると、そのような場合は自前実装のほうが良い可能性が高い。

OR検索はもっと簡単で

スペースの取り扱い方とか、case問題とか考え始めると難しい。 ただ、世の中そんな複雑な検索をしている検索エンジンはあまりないし、多分ローカルにそんなもの作ったところで報われないのでこれくらいでいいような気もする。

ANDまたはORではなく自由にANDとORを結合できるようにした場合は、expr自体に評価できるメソッドを追加すると良い。例えば

といった感じである。

あとがき

検索機能の実装自体は難しくないのだが、ChienomiをPureBuilder Simply化するという話になると結構難しい。

既にかなりの記事があり、検索からの流入も多いため、どうしても全記事に対してマップせざるをえない。 これもなかなか面倒だ。

だが、もっと問題Chienomiの記事は書き方が一定でない、ということだ。

Chienomiの記述形式はPOD, RDoc, ACCS2, PureDoc, PureDoc2, PureDoc2::Markdown, Pandoc Markdownがある。 PureBuilder SimplyはPandocでの処理を前提としているため、なんとかしないといけない。

過去記事については諦める方針ならばHTMLとして抜き出すという方法もあるのだが(Mimir Yokohamaでウェブサイトのサルベージでよく使う方法だ)、 できれば避けたいというのもある。

また、タグとカテゴリのつけ方が一定ではないため、これを処理しなければならない。

さらに厄介なのがメディアファイルだ。 WordPressはメディアファイルの使い方が独特だし、そのためにメディアファイルについてはWordPress上で追加する方法をとっていた。 さらにサイト移行時にメディアファイルを紛失したこともあって、結構大規模な作業になると思う。

そのことを考えると一筋縄ではいかない。

それはともかくとして、サイトの検索で非常に複雑な演算子を使いたがる人はまずいない、 どころかサイト内検索なんてほぼ使われていないに等しいので、基本的な検索機能で十分だと思うのだが、それであればこの通り実装はとても簡単だ(例によって設計で稼いだ感があるが)。

というわけでちょっとした実装例、そしてシェルスクリプトサンプルとして役立てば幸いである。

OVOフルデジタルスピーカー * Linux

OVOスピーカー

OVOスピーカー

宮城県のJDSoundがクラウドファウンディングで資金調達して開発したポータブルスピーカー、OVO。 小型ながらシアタークオリティのサウンドを発すること、D/Aコンバージョンを含まないフルデジタルであることを売りとしている。

非常に高い期待値でかなりの資金を集めたのだが、デリバリーが極度に遅れたことと、度重なる仕様変更で相当不満が高まっており、全体でみればスタート時点で評判はあまり良くなかったように見える。

私のところには2018-10-31に到着した。

なお、念のために前置きしておくが、私はプロの音楽家であるし、 スピーカーも何種類かのポータブルスピーカー、手軽なPC向けのElecom, Creative, BOSEのスピーカー、全く手軽ではないSony, DENON, FOSTEX, YAMAHAのスピーカーを持っているし使っている。

基本的な仕様

サイズ的には十分にコンパクトで、2つのMicroUSB Type-Bポートを持つ。

操作系はレバーボタンがふたつ、表示系はLEDインジケーターが16個、 脚は裏側と天面にある。

なぜ脚が天面なのか、というのは著しく疑問だった。 単にひっくり返るだけではなく、ステレオスピーカーなのでひっくり返してしまうとLRが逆になる。 設定でLR入れ替えは可能なのだが、わざわざ天面に脚をつける必要は全くなかったのでは…と思ったが、やってみてわかった。 横置きしたときにやや手前に傾くように傾斜しているので、正しい向きで設置するとスピーカー下向きになってしまう。逆にすれば上向きになる。なるほど。

MicroUSBポートはそれぞれ“Audio”, “Power”と表示があるのだが、この表示も大変にまずい。 USB audio deviceとして扱う場合はAudioポートに接続し、Powerポートは補助電源となる仕様だが、アナログ入力する場合、逆に“Audio”を電源供給としてオーディオデバイスとは“Power”で接続する。 非常にわかりにくい。

ちなみに、 製品版ではADCを含まないためにそもそもオーディオデバイスとの接続自体できない 。 これは致命的であるように思えた。だが、実はそうでもなかったことについては後述。

操作方法は大変わかりにくい。 レバーボタンを押すと設定モードになり、レバーで項目移動、ボタンで決定する方式。 なんかBIOS画面っぽい。保存または取り消しは反対側のレバーで行う。

このわかりにくさを緩和するため、インジケーターが意味する設定を表示するシールが付属している。 これがあれば操作方法さえわかっていれば戸惑うこともないだろう。

OVOはフルデジタルスピーカーであり、その内容としてはDnoteを使っている。 Dnoteの詳細についてはDigital Audio Lab.で掲載されている

Dtoneの基本的な特性は空間に余裕がない場合でも音量や音質を確保しやすいということだろう。 デジタルスピーカーそのものは昔から試行錯誤されてはいるのだが、いまひとつ実用には至っていない。 Dtoneが理想形というわけでもないと思うが、次世代の期待ということで刮目せざるを得ない。

LinuxにおけるOVO

基本的にダメだった。

PulseAudioから見ると-0.26dBでOVOのボリュームは0となり、-0.00dBで100になる。 あまりにもレンジが小さく、ボリュームコントロールが機能しない。 ちなみに、-0.26dbでOVOのボリュームは0になっているのだが、OVO自身はちゃんと信号を受け取っているのでインジケーターは適切に表示される。だが音は出ない。

また、USBバスパワーで駆動する場合(補助電源を使うとしても)ローパワーモードにしないとうまく動作しないかもしれない。

また、OVOはボリュームレバーでコンピュータ側のボリュームをコントロールするようになっているのだが、これはXF86VOLUMEキーとして機能するため、プライマリデバイスの音量が変更されてしまい全く機能しない。 さらにいえば前述の通り非常に特殊なボリュームレンジで動作することから、XF86VOLUMEDOWNしてしまうと-0.26dBよりも小さな音が設定され音がでなくなるため、仮にOVOをプライマリにしたところで何も解決しない。 この状態でボリューム・コントロールするにはデバイスボリュームではなくPulseAudioのアプリケーションボリューム側で絞って調整することになるのだが、これだと起動時にOVOから音を出すアプリケーションは音量設定前となり100%の音で出るし、OVOも100%で出すことになるから結構な爆音で出ることになる。ちょっと困る。

OVOの設定でローカルボリュームをonにした場合はちゃんと機能する。 恐らくLinuxで運用する場合は必須だろう。この場合はOVOのデバイスボリュームを100%に固定しておき、OVO側でボリューム調整が可能。 また、この状態であればデバイスボリュームを操作することでも音量調整ができる。

ただし、デバイス自体はやや不安定で、デバイスは接続されているが音が出ない、という状態に落ちたりすることがよくある。 また、ソースボリューム、というかソースのそのものの波形に影響を受けやすく、例えば随分音が小さいAmazon Videoなどはかなり小さな音で再生される。

OVOスピーカーのレビュー

試聴時にはわかっていたことだけれど、「ポータブルスピーカーとして無難なレベル」を出てはいない。

別に音が悪いということはないのだけど、表現力はそんなにないし、音が埋没しやすい。 標準設定ではLOW+2となっているのだけど、この設定はものすごく音がこもってしまい、ポータブルスピーカーの悪い音として普通のレベルになっている。

ただし、これは調整することで改善可能である。 HIGH+1またはLOW+1&HIGH+2が正しい音に近づくようだ。 LOWはBASSなのだが、HIGHはTribbleではなくヴォーカル音域あたり(2kHzかな?)である。

この状態であれば、確かにサイズからすれば驚くほどクリーンな音が出る、といっていい。

が、それはサイズ比、というか重量比である。 値段比で言うと製品版は2万円くらいするようなので、2万円くらいするスピーカーならもっといい音出せるからなぁ…と思ってしまう。

サイズ比でもやや微妙で、Victim Royaler Speakerというポータブルスピーカー(恐らく現在は入手不能)が非常に良い音を鳴らすのだが、体積的には2倍いかない程度、フットプリントは同等である。 ただし、重量に関してはこちらはOVOの比ではないほど重いので、重量比になると「すごくいい音を鳴らす」と言っていいだろう。

なお性質上筐体が非常に強く震えるのだが、そのために「置き方と置く場所」がすごく重要になる。 裏側を下にしてべったり置いたほうが響きやすいし、置く場所は板の厚い机の上がいい。 これで低音がぐっと強まり豊かな音になる。

難しいのは配置で、音がよく聞こえる位置というのは、「スピーカーを横置きしてスピーカーの上に頭をもってきたとき」である。 空間に対するスピーカーとしては非常に弱いニアスピーカーである。

また、音楽を鳴らしたときの話に限って話をしている。私は音楽家であって、特に映画フリークではないから、シアターシステムとしてどんな音声チューニングが好ましいか、ということはよくわからない。 ただ、低音はかなり出るし(そのかわりこもってしまうが)、高音を強調すれば越えも聞こえやすいので映画を見たりするのにはいいかもしれない。 実際、このスピーカーでアニメーション作品を見たところ、声優の演技は非常に聞きやすく、分離して邪魔にならない程度にクリーンに音楽が聴こえた。 OVOは元はGODJ OlusというDJシステムに内蔵されていたスピーカーであるため、DJ向きのチューニングなのかもしれない。 そう考えればこもった低音もある程度納得できる。

音楽を聴く上で大きなディスアドバンテージとなるのが中高音域の薄さだ。 ベースの際立ちはスピーカーとしては素晴らしい(スピーカーではベースはもわもわしてしまってベースの音は判別するのが結構難しい)のだが、アコースティックギターやピアノといった楽器がうまく響いてこない。Highを上げてやればこもってしまうことはなく粒立ち良く聴こえるのだが、粒立ちが良いために調和が悪く、広がりもないのであまり音楽的でない。多分根本的な問題は音の広がりがなさすぎることになるのだと思う。実際、スイートスポット小型スピーカーとしても非常に狭い部類で、ちょっと席を立つと音は一気に悪くなる。だから、もしOVOをでかいキャビネットに組み込んだらかなりいい音が出るのではないかとも思う。

音の広がり方という意味ではラップトップのスピーカーにすごくよく似ている。ラップトップのスピーカーでこの音が出てくれたら幸せなんだけど。

私はメインで使用しているコンピューターのシステムスピーカーとして4000円ほどのElecom MS-75CHを使っているのだが、 こちらは丸みのある音で疲れにくく、意外と音楽も聴けてしまう。それと比べると音は確実に良いのだが、音楽的に優れているかと言われるとちょっと困ってしまう。 もっとも、MS-75CHは極端にいいバランスを持ったスピーカーであり、ここまで使えるスピーカーはもっと高い金額でもないので比べるのは酷かもしれない。

19800円(税別)という価格はだいたいM-AUDIO BX5 D2と同価格である。これは35+35Wのスタジオモニターであり、かなり大きなスピーカーだが、音は素晴らしく良い。さすがにBX5と比べると、比べる意味がない程度には違う。 だが、BX5は設置場所も必要だし、ちゃんと鳴らすためには結構な音量が必要になるのでその点で見るとOVOに利点もある。デスクトップモニターのAV42(15000円くらい)にしても音は圧倒的に向こうが良いが、40Wクラスのデスクトップモニターは設置するためにはデスク自体をそれを前提として設計しなければならず、マルチディスプレイと組み合わせるのは相当難しいので、メリットはあると思う。

やはり価格に対する音という点ではどうしても気になってしまう。これで8000円くらいなら絶賛できるのに。 ラップトップと組み合わせやすいスピーカーとしても、同価格帯にTimedomain lightという強敵がいたりするため、ここでも明確なアドバンテージがない。 だが、「携行向きの」という条件をつけると話は大きく変わってくる。携行するときはまさかリスニングルームで聴くわけでもないので、これだけの音が出てくれれば、会議室のプレゼンテーションでも、騒がしい展示場でのデモンストレーションでも、彼女に家にお邪魔したときでも文句ない音を聴かせてくれる。

だからリスニングスピーカー(いわゆるオーディオスピーカー、あるいはモニタースピーカー)と同列で考えなければ素晴らしい音質なのだが、純粋に音質だけで勝負すると厳しいものがある。 基本的には音に不満はないし、OVOの使われ方を考えれば文句はない。リスニングという特別な条件を前提として純粋に音質だけを求めるなら最善ではないということだ。

もし家の中でステレオホームシアター的な使い方、あるいは音楽鑑賞用にスピーカーを求めているのであればOVOが最適解ということはないだろうと思う。 それはもっと大きいスピーカーのほうが向いている。 あるいは、固定的に使用されるラップトップ用スピーカーとしてもBOSE Companionもあることだし、実際私はBOSE MM-1も使っているけれどリスニング音質としてはこちらのほうがずっと良い。要はOVOの口上が過剰なのであり、「ポータブルスピーカー」という点を踏まえれば音は良いし、不満はない。だが、OVOがあれば映画館いらずなどというJDSound側の宣伝文句は鵜呑みにすべきではない

また、構造的理由から高サンプリングレートの音源はその意味を消されることとなる。 それが無意味なことだとは思わないが、ハイレゾ音源に本当に不可聴音域までの音を求めている人はこれでハイレゾ音源を再生すべきではない。

音量

デジタルスピーカーの潜在性という点で注目したい、「駆動電気量に比例するはずの音量がめちゃくちゃ出る」というのは事実だ。

Victim Royaler Speakerは音量も非常に大きいのだが、こちらは10+10Wである。 対してOVOは1Aと表示されており、USB給電は5Vであるため5Wである。 5W、この筐体でこの音量はすごい。机の上だとさらに大きくなる。(この場合筐体が巨大になったのと同じ話だが)

シアタークラス、とは言わないが、とりあえず防音のないマンションで聴く音としては限界以上に出る。 6畳クラスの部屋ではうるさすぎるほどだ。普通に20Wか30Wクラスの音量といった感じ。

ラップトップだとデモンストレーションするときに音量が足りない、というケースは非常に多いのだが、この問題はあっさり解決される。 音量だけの問題であればもっと小さなポータブルスピーカーでも良いのだが、音質的にもリスニングスピーカーとして選択する領域では言うほどのことはないだけで、BGMとして流しておくのになにも不満はない音であるため、プレゼンテーションやデモンストレーション用途には非常に良い。 実際、私はこの目的で購入したのでなかなか満足だ。

サイズと重量と携行性

サイズと重量に関しては携行性最優先で考えるとだいぶ不満がある。

コンピュータ系の仕事を外でするタイプの人は持ち運ぶ機材も多いので大きめのバッグを使っているだろうが、それでも結構なスペースを取る。 コンパクトなバッグを使っている人は収まらないかもしれない。

重量的にも気にならないほど軽いとはいえず、これひとつ持つことで重量感が変わる。 だから、「携行性が良い」とは言えない。

が、間違いなく「携行性はある」。 Victim Royaler Speakerは音も音量も大変優れているが、体積的にカバンの中では相当邪魔になる上に、重量がかなり重いのでよっぽどのことがない限り持ち歩く気にはならない。 音楽系のなにかをするときくらいのものだろうか。スタジオだとだいたいコンソール経由で音が出せるから、ダンススタジオでの練習なんかに使う程度な気がする。 だいたい、重量がありすぎて、無造作にカバンの中に入れてしまうと壊れそうだ。

OVOは常時携行する気にはならない重さだが、必要であれば持ち運ぶのが苦にならない程度ではある。 音質と音量、そして携行性のバランスを考えたときに、「ただ音さえ出ればいい」というわけではなく、きちんと音質も気にしつつ音量も出したいようなケースにおいては許容されるギリギリのバランスであると思う。

どちらかといえば気になるのは音の狭さだ。 音が狭いため望ましい設置を行うためにはキーボードの手前に置く必要があるのだが、そこまでコンパクトというか薄いわけではないので、すごく邪魔である。 ケーブルが出るのでなおさらだ。

製品版でADCが省かれたことは後退ではないかと考えたものの、実際のところ電源確保が別途になることも考えると、あまりポータブルオーディオと組み合わせるようなものではなく、そのような場合はまあまあ準備をするもので頻繁にある状況ではない、と考えると別に別途ボックスがあっていいか、とも思う。というか、そこまでしてOVOで聴きたいかが疑問。なんだか高価そうだし。

結論

「高い」「言い過ぎ」 これに尽きると思う。

携行性の良いポータブルスピーカーとしてAUKEYのスピーカーを持っているのだけど(これはメーカーからご提供いただいたもの)、音量はまぁまぁでるものの騒がしい空間だと流石に厳しいし、音質も「音楽も聴くに耐えないわけではない(ラップトップスピーカーよりはいくらかマシ)」という程度に留まる。

Victimのポータブルスピーカー(こちらはセラーにご提供いただいたもの)は音質も良く音量も出るが、重すぎて携行性に乏しい。

私がOVOに期待したのは、「講演とかプレゼンとかデモとかでちゃんと聴こえて、音質も添え物じゃなく惹きつけられるくらいのものだといいな」ということなので、その期待には100%応えてくれたから、私としては満足だ。

だが、それはクラウドファンディングで11000円ほどで手に入れたからであって、2万円は高い。

音楽鑑賞用のスピーカーとして見れば2万円の音ではない。ポータブルスピーカーであることを抜いてしまったら、そんなに音は出ていない。 まぁ、「動画視聴用」と強調しているので、オーディオスピーカーとして評価すること自体が間違っているのかもしれないけど。

そして、「映画館を完全再現」はできていない。だいたい、それはいくらなんでもスピーカーアレイをナメ過ぎだ。スピーカーアレイはモノもそうだが、その配置にはものすごくテクニックが必要になる。PAエンジニアをナメてはいけない。

だが、言っていることの中で間違いなく事実であるポイントがある。 それは「声が聞き取りやすい」だ。

私が持っているスピーカーは全てモニター、あるいはオーディオスピーカーなので、個人的なシアタースピーカー/AVスピーカーの経験はそもそもないのだが、 私が持っているどのスピーカーよりも声は聞き取りやすく、アニメでもYouTubeでもスピーカーにおいて常に感じるセリフの聞きづらさがかなり解消される。 確かに、「動画視聴用」程度のライトな感覚ならば文句の出ようがない。いや、それでも2万円は高い気がするけれども。

価値は間違いなくあると思うのだけど、絶賛するなら8000円、賞賛するなら15000円くらいで出してほしかったところだ。 そして、大言壮語に良いことはない。