【Manjaro/Arch Linux注意】Yaourtは廃止になりました

すごくニュースだと思うんだけれど、全然話題になっていないけれど。

AURヘルパーである YaourtはAURからなくなりました

もう随分長いこと「非推奨」とされてきたのだけれど、ついになくなった、というかたち。

AURヘルパーの中ではYaourtが最も親しまれてきたし、最も有名だった。 「Yaourtを使う」というのが当たり前になってもいた。

けれど、近年はセキュリティ上の問題があり、メンテナンスされていないことからobsolateになっていた。 で、今ついにAURからなくなった、ということ。

これに伴って、CommunityパッケージになっていたManjaroでもYaourtは廃止に。

今後はyayなり、Trizenなりを使っていくことになる。

そのうち「Yaourtを野良ビルドして使う」みたいな記事が出てきそうだけれども、 危険なのでやめましょう

Archwikiでは2019-05-20現在、日本語版はそのままであるものの、英語版はYaourtに関する記述自体が削除されている。

カスタムキャストでキャストデータを移行する

アプリとしての出来が悪いままのカスタムキャスト

ドワンゴのVTuber戦略は相当不調らしい。 まぁ、「当然だな」という越えがおおかったりもするのだが、登場当初は非常によく遊ばれ、期待も大きかったカスタムキャストがいまひとつ普及していないのも、その現れなのかもしれない。

カスタムキャストは元はアダルトゲームのカスタムメイドがベースになっている。 あれは、エディット機能自体は優秀なものの、DMM版含め出来がよくないという評判がもっぱらなので、必然なのかもしれない。 ありとあらゆる面でいまひとつであり、そのひとつとして「引き継ぎ機能がない」というのが挙げられていた。

やがて引き継ぎ機能が実装されたのだが、著しい「コレジャナイ感」が漂っている。

ほとんどの人は引き継ぎたいのはキャストデータだと思うのだが、キャストデータは対象外、というか引き継げるデータはほとんどない。 キャストデータを作るのは結構時間もかかるし、再現するのは困難なので、キャストデータが引き継げないとそもそも使い物にならないと思うのだが。

データをコピーすればOK

説明にある通り、キャストデータは端末に保存されている。 保存場所はAndroid/data/jp.customcast.cc2/以下である。つまり、このフォルダ以下をコピーすれば良い。 幸いにも現在データチェックは甘く、キャストデータをピンポイントに上書きしなくても、必要なデータを再ダウンロードする形で通してくれる。

ただ、私が試した限りだとgvfs MTPの制限なのか、このフォルダ以下にコピーすること自体ができなかった。 ただし、ファイルの作成や上書きはできるため、

のようなシェルスクリプト(これはサブフォルダ用)で処理できた。 これ以上深いディレクトリの中身は放置して良いし、cache以下は気にしなくて良い。

Windowsユーザーはどうすればいいか、という話は私が取り扱うべき話ではないから、 このフォルダをコピーすればいいよ、という情報を元にがんばっていただく方向で。

論理的思考力 初歩

授業や講座でも人気の論理的思考力のおはなし。最近だいぶアップデートされたので、これをChienomiでも紹介することとする。

論理とは

周辺事情から間接的に事象を確定する(観測する)ことである。

論理は“真”または“偽”で表す。成り立つものが“真”、成り立たないものが“偽”である。 「部分的に成り立つ」ということはない。成り立たないこともあるのであれば成り立つことが証明できていないからだ。 偽であることは「必ずそうでない」ことを証明するのではなく、「必ずしもそうはならない」ことを証明するものである。

よって、物事は圧倒的に偽になる可能性が高く、真であることとは本質的に同一または包括関係であることが多い。 真であるとする証明が正しくないことを証明するためには、わずか一例でも成り立たない例を示せばよい。

論理は因果関係である。「Aであるならば、Bである」というものだ。 AとB(因果)を逆にしたものを「逆」という。 つまり、「BであるならばAである」ということだ。

逆は必ずしも成り立つとは限らない。特に、AがBを包括するとき、AであるときBは十分条件を満たすため真になるが、BはAの一部でしかないためBであってもAでない場合というのが存在することになる。 もし、AとBが同一であれば逆も真となる。

AとBが共に否定関係にあるものを「裏」という。 つまり、「Aでないならば、Bではない」というものだ。

これが成り立つためには、AがBにとっての必要条件である必要がある。 AがなくてもBを満たす方法があれば裏は成り立たない。 そして、「裏が成り立つ」と「AはBにとっての必要条件である」は等しい。

なお、論理的に言う「否定」とは「論理反転」を意味する。だから、「〜ない」を否定すると「〜である」になる。

「逆」と「裏」の両方にあたるものを「対偶」という。 「Bでないとき、Aではない」である。

対偶はあまり使わない。意味としては裏を逆にしたものであり、BがAの必要条件であることを意味する。 裏も対偶も真であるのに逆は偽である、というケースはだいぶ稀だ。 互いが必要条件であるならば、両者は密接な関係にあると考えて良いからだ。 ただし、必須の包括状態にある場合には、逆だけが偽になることもある。

これは高校数学でやるのだが、高校では数学をやらないケースもあるため、知らない人もいるだろう。 私も数学ではやっていない。

余談だが、「逆に言う」「裏を返す」は、まんま論理学的用語であるため、ちゃんと逆ないし裏になっていないと、私としては教養のない人だなぁ、という感想を抱く。

論理の初歩にナンプレを

ナンプレ(ナンバープレース)というパズルがある。

かなりメジャーなもので、やったことのある人も多いだろう。 一時期、Nintendo DSがリリースされたブームになったりもした。

ルールはシンプルだ。9×9の81マスがあり、各マスには1から9の数字が入る。 ただし、制約があり、縦列、横列、及び3×3で区切られた中には重複する数字を入れてはいけない。

ルールは以上だ。

このルールの時点で論理的に解法を求められる。 ちなみにもナンプレの攻略テクニックとしてこれ以外の方法があったりするのだが、ここはあくまで普通に論理的に解くこととする。

空行の候補は1から9の数字である。 これは、ルールによって定義されており、直接的に表現されている。

そして、ルールから「縦列、横列、または区画において出現している数字は除外できる」ということが導ける。 これら出現している数字をあてはめた場合、ルールに反することになるからだ。

ごく簡単なナンプレ問題では、このように除外することで候補がひとつしか残らないマスが出現する。 マスには数字を入れなければならないため、候補がひとつになった時点でそのマスの値は確定する。 このように順次確定することでマスを埋めることができる。

そのマスだけを見たとき、直接定義されているのは「1から9の数字が入る」ということだけだ。 だが、周辺事情によってそのマスの値は確定することができる。 それが確定するのは、そのマスの値が残された候補でないとき、そのパズルのマスを埋めることができない、という命題が真になるからだ。 よって、そのマスは最後に残された候補の値にならざるを得ない。

これは、「周辺事情によって他の可能性が消去される例」である。

もう少し難しいナンプレ問題だと、複数の候補が残る。 この場合、そのマスに値を入れるとその影響によって候補が残らないマスというのが発生する。

だが、そのマスの正しい値というのはわからない。候補1になるマスは存在しない状態だ。 しかし、いずれかの候補値を仮定すると、結果的に他のマスの値が確定することになる。

このとき、マスが「答を入れることができない」状態になることがある。残される候補が0になるのだ。 これはつまり、仮定した値が間違いであることがわかる。よって、仮定したマスの候補から除外できる。

これは、「Aの値がXであるとき、ゲームBはクリアできなくなる」が真になるため、「Aの値はXではない」が成立するのである。

このように問題を一旦仮定することで、成立しなければ除外するということができる。 これもまた、「周辺事情によって偽であること良いが明らかになる例」である。 先に述べたように「AであるときBではない」の裏「AでないときBである」が成立するわけではないことに注意してほしい。 例え仮定した結果成立したとしても、それによって真であることが証明されるわけではないのだ。

実際、ナンプレでも複数の値によって仮定しても確定する値が矛盾をきたさないこともある。 実のところ、ナンプレの場合は基本的には最終的には埋められる値は1つしかない。もっとも、数多い空きマスの全マスに対して仮定を適用するのは、人間にはちょっと無理だが。 だが、現実にはそうでない場合も少なくない。想定すべき全体像がわかっているとは限らないからである。 そのため、例え直ちに矛盾をきたさないことが、その仮定が正しいことを証明するわけではない―ただし、正しいのではないか、という推測は成り立つ。

パズルと論理

ナンプレに限らず、パズルではこのような論理性を持った論理パズルが多い。 クロスワードのような潜在的に特殊な論理性を要求するものを割と珍しい。もっとも、ビデオゲーム用のパズルは全く別だが。

このような最も基本的な論理の適用方法は消去法である。 まず現在の状態から採りうる候補を列挙し、状態の変化に合わせて消去していく。 回りくどい方法だが、「こうだからきっとこうだ」などと推測するよりはずっと正確だ。

ボードゲームも、総当りすることができるのであれば、このような論理ゲームとして成立する。 実際、マルバツゲーム程度であれば論理ゲームとして成り立つ。 ただし、実際はそれが不可能であるため、別の方法をとることになる。

「らしさ」と論理

ナンプレにおいては明確に制限された規則によって論理を求めることができた。 だが、実際にはそのような状況を設定することができないことのほうが多い。そこで、逆に規則のほうを設定して、「論理が成立する条件」を求めるという手法もある。

規則は前提条件である。命題自体には含まれていなくても、その命題が設定される時点で常に適用されるものになる。 例えば、ナンプレであれば、「ナンプレのルールにおいて」という規則がある。そして、ナンプレのルールという形で様々な条件が設定されている。

規則がまるで導入されていない状態で成り立つ論理というのは「真理」だが、これはかなり限定的であり役に立たない。 (さらにいえば、真理ですらも最低限、「この宇宙における法則において」という規則が導入されている)。 そこで、有益な論理を導出するために必要な規則を探すのである。

やってみればわかるのだが、規則が限定的になればなるほど論理を成立させるのはたやすくなる。 だが、実際には「規則は適切に限定されていなければならない」のである。これは、必要以上に限定的な規則では有益ではない、ということだ。 ちなみに、導入した規則の存在を忘れてより一般性がある論理であるかのように言うのは愚か者である。

基本的には成り立たない論理というのは、それが当てはまる場合と当てはまらない場合の両方が存在するわけだが、規則のほうを限定していけばいずれ成り立つ。だが、その場合、「命題が何かを証明しているわけではなく、規則によって結果が必然的である」ということもあり、このような場合は有益ではない。

有益な論理というのは、「規則、命題ともに適切に限定されており、同じことを指してより限定的である以外に成り立たせる方法がない」というものである。 そして、論理の追求とは発見している論理や規則を、これに限りなく近づけることである。

論理では確定的事象を扱うため、確率の話は基本的にはしない。 だが、観測においては「確からしさ」というものを取り扱う。これは、確率の話である。

勘違いされがちだが、確率というのは「割合」とは違う。観測された事象のうちN%が該当するから事象の成立する確率はN%である…というほど単純な話ではないのだ。 (もちろん、この物言いがやや統計学に喧嘩を売るものであることはわかっているが、確率が統計だけのものだと思ってもらっては困る)

それが真である確率を強調していうのに、語義は同じだが「蓋然性」という言葉を使うことが多い。 「真である確率」とは基本的には「真にならざるを得ない条件」の蓄積である。

例えば、「地球には雨が降る」という事象の蓋然性について考えるとき、まず地球圏に(十分な量の)水分が存在することに着目する。 そして、地球圏の温度が均一たり得ないことを踏まえて考えると、その水分は偏りを持って移動すると考えられる。

この時点で「地球には雨が降る」を偽たらしめるのは、水分が大気中に混ざったまま浮遊していられる量である場合や、地球上に雨となりうる温度条件が存在しない場合などだ。 気象の話を本格的にし始めると多くの読者を置き去りにしてしまうのでイメージの話にとどめておくが、これら「偽の可能性」はいずれも否定しうる。

結果として、「地球上には雨が降る条件が揃っている」「地球上で雨が降らない条件は満たすことができない」ことから「地球には雨が降る」を真とみなすことができる。

しかし、物事によっては「これ以上偽たらしめる条件がない」ことを確定できない場合がある。 あるいは、偽たらしめる命題が偽であることを証明できない場合もある。 これらの不確定部分を「確かであること」から差し引いたのが、事象の確からしさ、ということになる。

なお、この節は非常に短絡的に述べているのはわかっているし、それはブログとして書けるものの制約によるものなので、論理学・天文学・量子力学・統計学・気象学できる系諸兄にはお見逃しいただきたい。

予測可能性

事象は連続する、という自然な感覚がある。 これは、自然においてそうなっているからなのだが、感覚的にはそれを拡張して捉えようとする。

これは理系文系の違いであると言われることもあるが、基本的には法則性・規則性が強いほうが予見できる、というのは事実だ。 というよりも、法則性・規則性がないものは予見できない。

このようなものを我々が強く意識するのは命名規則においてだ。 例えばメソッド名にaddElement, delElement, editElementがあったとする。 この状態でaddGroupが登場すれば、きっとdelGroupeditGroupがあるに違いないと考える。 もちろんそうであるべきで、いきなりgroupDelchangeGroupValueなんてメソッドを導入すべきではない。

似たような話だと、Unix系ユーザーアカウント操作コマンドがある。 useradd, userdel, usermodは一連のコマンドなのだが、これとは別にadduser, deluserというコマンドもある。 これらは全く別の体系にあるコマンドであり、useraddusermodとはコマンド形式からして違う。

ところが、これだけ提示されるとmoduserがある、と予見してしまう。 実際にはなく、vipwを使うのが基本であった。ところが、いくつかのLinuxディストリビューションは、adduser及びdeluserを採用した上で、usermodだけを導入する、ということをしてしまった。これだと、「変更コマンドだけ語順が逆、しかも書き方も全く違う」という事態であり、大変な混乱をもたらす。実際、これによって混乱しになっていた。ている人は多かったし、LPICでも結構な間違いポイントになっていた。

コマンド関係で言うと、serviceコマンドは引数が「サービス アクション」の順なのだが、systemctlコマンドは「アクション ユニット」の順で、このあたりも予見可能性を低下させている。

このような予見は非常に強く働く。あるワードが登場した時点で、例え法則性を提示されなくても、法則性があるのではないかと考えてそれを探す、という行動は極めてよく見られるし、検索語句としてもよく現れる。 このことから、「人は非常に強く物事に法則性を見出そうとするし、予見可能性が低いものを非常に嫌う」ことがわかる。

もうひとつよくある話だと、+=演算子の話がある。

A = A + Bを表すのにA += Bと書けるのだが、四則演算は減算(-), 乗算(*), 除算(/)もあるから、-=, *=, /=があると考えるのが自然であり、多くの人はそのように予見する。 そして、そうなっている言語も多い。

だが、実はそうなっていない言語というのも結構ある。 例えばzshは+=しかない。

この理由は、そもそもzshは四則演算がArithmetic evalutionの中でしか行われず、裸で演算子を書くことができないからだ。 そして、+=は配列に対するpostpendとしてのみ書くことができ、-=は文意が不明瞭になるため実装されていない。 実際、Arithmetic evalutionを使って(( A += 10 ))のような書くことはできる。

+=を四則演算以外に適用できるようにするケースも多い。少なくとも文字列の追加には使えることが多いし、配列の追加にも使えることが多い。 Rubyでは+メソッドが定義されてさえいれば、A += BA = A + Bとして評価させることができる。(ただし、例によってAは一度しか評価されないので同一ではない)

そのため、+=は汎用的に使える、と予見しがちである。しかし、Perlでは+=は数値演算以外に使うことができない。 そもそもPerlでは+演算子事態が数値演算に限定されており、文字列連結は.演算子を使う。 Perlは最近の大抵の言語よりも古い言語なので、Perlに責任はないのだが、今は一般に+=を一般化して使うことができるようになっているため、Perlよりも新しい言語から学び始めた人はPerlの挙動に予見可能性が低いと腹を立てることになる。

さらにいえば、+=は非常にメジャーな演算子であるため、JavaScriptに+=演算子がないことを腹立たしく思う場合もある―私はとても思うのだが、検索してもあまりそのような意見は見ないので、ひょっとしたらマイナーな意見なのかもしれない。

この予見可能性は基本的に「その人の中で成立しているように感じている論理」に基づいている。 法則性というのは観測の限りであり、別にそうなるものだという証明がなされているわけではない。だが、見出した法則性というのはその人の中では成立している論理と等しく、これに反するものは非常に強く裏切られたように感じられる。

設計におけるユーザビリティとしては予見可能性を高く保つことは何よりも優先される。 これは、APIであろうが、UIであろうが、挙動であろうが全てに言える。 予見可能性の低いUXというのは、例えばゲームで爽快感の低い操作を強いられて、ようやく動きが出てきて操作に追従するようになってきたと感じた途端に長いロードが入る、というのを繰り返すような不快さを提供することになるのだ。

そして、予見可能性を高めるということは、その枠組みの中で成立する論理を提供する、ということでもある。 例えばvipwは古くからあるコマンドだが、これは/etc/passwdファイルに変更を加える。これはユーザー情報のファイルであり、であれば/etc/groupを編集するvigrがあるはずだ…と予見する。特に、後に/etc/sudoersを編集するvisudoが追加されたことから、vi$targetという法則性を見出すことができるようになったという点も大きい。 vigrはかなり長いこと存在しなかったが、やがて追加された。これは、「ユーザーアカウントに関する編集を行うコマンドはvi$targetである」という論理性を創造した、ということになる。

自分でコントロールできる範囲であればより積極的にそうすべきである。 例えば、parmas[user]パラメータがparams[user][name]のように連想配列として提供されるのであれば、params[group]のようなパラメータが例え項目がひとつしかないとしても、params[group]によって値を返すのではなく、params[group][name]のようにすべきであるる なぜならば、そのようにすることでparams[$type][$term]が予測できるようになるからだ。 良い名前は名前だけでそれが何に属するどのようなものかを推理する余地を与える。

論理的思考

「世に論理的思考と呼ばれているものは論理とは関係ない」とよく言われるのだが、ここではちゃんと論理に基づく思考を指して論理的思考としたいと思う。

論理的思考とは「AのときBたりうるか」に基づいて判断することである、と言ってよかろうと思う。 この思考が究極まで至ることができるならば、全てを知ることができるのだが、残念ながら観測を含めそうはならない。 そして、基本的には(思考停止しない限り)時間があれば論理的思考量は増やすことができるので、時間に対してこの検討がどれだけできるか、というのが論理的思考力、ということになる。

論理的思考において、既知の箇所はスキップすることができる(もし、既知であるという判断が間違っていたとしてもスキップしてしまうのだが)ため、論理的思考力によって論理的思考量が一律に決まるわけではない。 例えば将棋やチェスにおいては、必ずしも論理的思考力に優れる者が勝利するわけではなく、定石などを知っていればある程度確定した状態からスタートできるので、大きなアドバンテージを築くことができる。

また、将棋やチェスなどにおいては基本的に時間制限があり、考えうることを全て考えて指すことができるわけでもない。 このため、単純な論理的思考力によって決着がつくわけでもなく、思考経路によって大幅に左右される。 いい経路を選択すれば論理的思考量に対して得られる結果がよりよくなる。だから、現実にはよい経路を選択できる勘のようなものも非常に重要になってくる。

論理的思考において重要なのは「期待しない」ことである。 人はなにかに期待すると、そうではない結果を否定したい、というバイアスが働く。だから、論理を歪めたがる。 「情報は情報であり、事実は事実であり、論理は論理である」ということを見失わないことが大切だ。論理に血が通う必要などない。そんなものは、言動において通わせれば良いのであって、論理を歪めるために使うものではない。

また、論理の正しさを肯定しないというのは、自分の都合の良いように事実を肯定歪めようとすることである、ということも覚えておいたほうがいいだろう。

Chienomiは結論を提供しない

Chienomiに限らず、私が書く文章において結論は提供しない、というのは私の信条である。

なぜならば、人が思考する上で有益なのは情報であって結論ではない。 情報さえあれば、人はその論理的思考力と価値観によって結論を出すこともできる。

結論が声高な文章は不快なノイズである。 もちろん、経験に導かれる結論はあってもよいのだが、そこに一般性があるとするのはノイズ以上のなにかにはなりえないだろう。 これは、当人がいかなる結論を得たか、ということとは異なる。それは単なる情報であり、意味のあるものだからだ。

そして、私の書く文章は、何らかの特定の結論に達することを期待しているわけでもない。 なぜならば、私自身が特定の結論を持っているわけではなく、あくまでその時々の判断と判断材料にあるに過ぎないから、「この文章はこういうことを結論としているのだ」と感じ取ってしまっているのであれば、それは全くあなたの気のせいである。それは、もしかしたら現代教育の被害なのかもしれないが。

文面からしか文意を導けないのは、論理的思考力の欠如だろう。 私は何かを書くときには論理的完全性にはかなり気を使っているつもりなので、あなたの論理的思考力を活用すれば、より多くの情報が得られるはずだ。 もっとも、それが有益かどうかについては保証できるものではないが。

Linuxデスクトップ環境の比較

Linuxデスクトップ(Unix系デスクトップ環境)の使い心地というのは使いこんでみないとコメントもできないものなのだが、なかなかその特性を理解するまでそれぞれを使い込むのも難しい。 特にまだLinux歴の浅い方はどれを選んで良いのかわからないこともあるだろう。

そこで現行のデスクトップ環境からメジャーなものについて、私が感じる良い点、悪い点をまとめてみた。 あくまで私の視点なので、異なる意見もあるだろうが、そこはあくまで1ユーザーの意見とご了承願いたい。

また、MATE, Deepin’, Pntheon, Budgie, Lumina, LXDE, LXQtなどの他のデスクトップ環境、あるいはEnlihgtenment, fvwm, i3, awesomeなどの他のウィンドウマネージャがあることは承知しているが、私が普段使っていないのでコメントするレベルにはないことも、併せてご了承願いたい。

GNOME

良い点

  • Waylandに最も良好なフィーリングを見せる
  • スクリーンショットツールがとても使いやすい (ただし設定はgsettingsコマンド)
  • ウィンドウボーダーのデザインが豊富で、良いものが多い
  • ランチャーがコマンド実行になっており、検索前提のアクティビティ機能と相性がいい
  • Gnome Keyringは様々なキーをいい感じに管理してくれて使いやすい

悪い点

  • 設定の大部分が隠されており、テーマ設定などの基本的な設定もできない。また、壁紙もコマンドを打たない限り$XDG_PICTURES_DIR直下の画像ファイルに固定されている
  • ウィンドウタイリングが左右にしかできない
  • ウィンドウフィッティングが弱く、表には設定もない
  • Nautilusで右クリックにおけるアクションメニューが簡単に設定できるようになっていない
  • Alt+マウスドラッグによるウィンドウ操作ができない
  • メニューが非常にわかりづらく、メニューが少なすぎて必要な機能を満たさない
  • 「1画面しかなくて、1画面に1アプリしか表示しない」が基本なので、ウィンドウはクローズボタンしかない
  • アクティビティ機能はプログラムをカテゴリ分けしてくれないので、探すのが非常に辛い
  • ウィンドウスイッチャがなく、常にアクティビティから切り替えるかタスクスイッチャから切り替えることを求められる。カレントウィンドウのメニューは表示されるが、マルチディスプレイの場合はプライマリディスプレイ以外無視される 
  • 設定がホームディレクトリ以下になく、バックアップしづらい

捕捉

私はGNOMEが好きではないので、すごく否定的な意見であると考えてもらっていい。 「Linuxなら出来て当たり前だったことをわざわざできなくしている」ことに私は好感を持てない。

Gnomeアプリケーションにはいくらか魅力的なものもあるけれど、デスクトップコンピュータ、とくにマルチヘッドディスプレイや、大画面で使うのに適したものだとはとても思えない。

Gnomeはパソコンよりもタッチデバイスを優先しているのだと感じるし、パソコンもせいぜいが今風なラップトップのみを想定しているといったところだろう。 そして、様々な機能を要求に応じて使いこなす努力するユーザーではなく、機能を使う気がなく、機能を与えてほしくないルーザーのみに親切、という印象である。

ただ、それは解消不能な一部の問題(例えばウィンドウタイリングやAltマウスイベント)を除けばgconfなどによって解消することができ、 およそ「Windowsでレジストリをいじる」のと同じレベルで操作することにより、ユーザーによっては満足できるものに仕上げることもできるだろう。

Cinnamon

良い点

  • 非常に使いやすいウィンドウタイリング。 Super+カーソルで「現在の状態を基準にカーソル方向へタイルする」という挙動。また、タイルした状態でリサイズもできる
  • ウィンドウタイリングしたあとウィンドウを移動すると元のサイズに戻すようになっている。これは、タイル状態でリサイズした場合も同様で、タイルにウィンドウサイズのステートが影響されない
  • 軽い。 ハードウェアアクセラレーションが効くためXFceと比べても格段に軽い
  • ウィンドウフィッティングが設定可能で、かなり使いやすい。タイルしたウィンドウに対してもフィットするため大量のウィンドウを並べるのも楽
  • Alt+左ドラッグ(move), Alt+中クリック(windows menu), Alt+右ドラッグ(resize)全てに対応している
  • 設定項目はやや少ないが、必要なポイントは抑えていて「ほどよい曖昧さ」になっている。設定が大変ではなく、かつ必要な設定はできる傾向がかなり強い
  • Gnomeのメリットだったスクリーンショットと鍵管理はGnomeと同じものを使用しており、同じメリットが得られる
  • Nemoアクションがiniファイルになっていて、結構書きやすい (ただ、現在ちょっとバグってもいる)
  • ウィンドウラベルのマウススクロールに対して細かな設定が効く。アルファ設定も可能
  • Nemoが単独で動作し、軽いファイルマネージャでありながら、gvfsによるマウントにも対応していて使いやすい
  • Alt+F1でワークスペース選択になるのが便利。数字キーで選択できる
  • マルチヘッドディスプレイでフルスクリーンにしているとき、パネルは「パネルがある画面上でフォーカスされているのが他のウィンドウであるときのみ表示する」という理想的な振舞い。フォーカスウィンドウはフルスクリーンウィンドウより前にくる
  • 選べるデスクトップアニメーション
  • 純粋なコマンドラインのランチャと、検索可能なメニューの組み合わせ
  • 左右へのパネル配置に比較的強い
  • 合理的な「フォントはDPIではなく倍率で設定させる」
  • DPのプラグアンドプレイ問題で「復帰できない変更をされる問題」が比較的少ない
  • ボリュームアプレットがマイクのミュートコントロール、デバイス選択、プレイヤーコントロールまでできる便利設計
  • フォント設定機能がフォント数が増えても軽く、使いやすい
  • ファイルダイアログが未選択状態でキータイプを始めると直接パス入力できる仕様
  • Conkyの表示が一番安定している
  • ウィンドウスイッチャからQで直接ウィンドウクローズが可能

悪い点

  • 通知を1件ずつ表示するため、大量の通知がある場合いつまでクリックしても終わらなくなる
  • 通知の有効期限をスクリーン上ではなく通知エリア上の時間として扱う。これは、恐らく正しくない
  • 壁紙がウィンドウごとではなく共通である。設定が楽、ディスプレイ認識でおかしなことにならないというメリットはあるが、残念には感じられる
  • ウィンドウデコレータがMetacityベースでデザインがあまりよくない
  • アプレット機能があるものの、動作しないものが多く、ほとんど役に立たない
  • 起動がやや遅い

捕捉

基本的に「すごくいいバランスで、うまい具合に作られている」のがCinnamon。 機能豊富というわけではないのだが、GNOMEやKDE Plasmaのように主張をぶつけてくる感じではなく、「どうあるのが自然か」「どうなっていれば使いやすいか」ということに向き合って作られている感じがする。 (ただ、Cinnamonはissue reportに対して割と対応は冷たいのだが)

ほとんどの場合要求を満たすことができ、完全ではないが不満というほどではないという状態を作るのがうまい。 至らないところもあるが、使い勝手なら最高だと思う。私は何に移ってもCinnamonに戻ってきてしまう。

ややいまいちだったウィンドウスイッチャは、Windows7以降と同様のアイコンスタイルのものが導入されて使いやすくなった。 グループに対してはホバー時だけでなくクリック時にウィンドウリストを表示する機能もあるが、これはまだbuggyである。 垂直表示を有効にしていると、ウィンドウグループを縦に表示し、さらにそのウィンドウから派生したウィンドウは水平に表示するという器用さを見せる。 懸案だった「.desktopファイルに書かれている情報を使ってくれない」という問題も解消してくれている。

ClutterとNemoの出来の良さが圧倒的で、総じて非常に使いやすい。派手な機能はないが極めて実用的だ。 Cinnamonの欠点を探してみたのだが、これといってあまり見つからなかった。以前はいくつかあったのだが。それが戻ってきてしまう理由かもしれない。

KDE Plasma

良い点

  • 非常に充実したアプリケーション群でクオリティも高い
  • 非常に充実した設定項目。特に電源管理が優れている
  • KIM Panelが格段に使いやすく、Fcitxのウィンドウも統合されていて入力が快適
  • Alt+マウスドラッグによる操作をカスタマイズできる
  • デザインが良い
  • KDEパネルは機能が多彩で、ウィジットも強力
  • 0.1倍単位のUIスケーリング。Gtkアプリケーションにも対応する
  • 検索のみではあるもののランチャもメニューも強力な検索で使いやすい
  • KDE Walletはウェブブラウザのパスワードを一括して管理してくれるので安心感がある
  • 設定ファイルが素直にホームディレクトリ以下にあるためバックアップしやすい
  • Qtの利点を活かした非常にスムーズなスクロール
  • ディスプレイ接続時のアクションが良好で、プレゼンなどでプロジェクターを使うときにも使いやすい
  • ディスプレイを「重ねて配置」できる
  • ウィンドウフィッティングが非常に素晴らしく、ピタッとウィンドウを並べることができる
  • フォントレンダリングに手が入っているのか、ちょっと綺麗
  • 通知の扱い方が適切で使いやすい

悪い点

  • やや不安定
  • サイズの異なるディスプレイを並べると、ディスプレイ位置がおかしくなったり、パネルを失ったり、壁紙を失ったりする
  • ディスプレイの再接続時に本来のディスプレイ設定に復帰しない
  • よくアイコン位置がおかしくなる
  • プラズマにログインしてからログアウトし、再度プラズマにログインするとスケーリングがおかしくなる
  • Balooを有効にしているとキャッシュファイルなども画像に含められてしまい困る上に、inotifyの上限に到達してもさらにファイルを追加するためシステムが終わる
  • AkonadiやKDE PIMは便利ではあるけど、「いらないことをする」感じも強い
  • KDE WalletがGnome Keyringのように暗黙にSSHエージェントのように振る舞わない
  • 設定が独特で、XDG標準を遵守しないし、XDGディレクトリもあまり尊重しない
  • Dolphinはアクションを追加するのも面倒で、XDGディレクトリを無視し、ブックマーク機能はない
  • ウィンドウタイリング後にウィンドウを移動すると、ステートはタイルされていないことになるが、元のサイズには戻らない
  • 壁紙の設定が面倒。フォルダの追加は知識が必要で、全部まとめられるので

捕捉

理想は高く、理想に届かないKDE Plasma。 KDE Applicationsに満足するか否かが分かれ目になる。

ウィンドウフィッティングはCinnamon以上に良好で、ウィンドウを並べるのは得意。 ただし8方向タイリングはショートカットキーの設定が必要になる。 一応、マウスでエッジに持っていくとタイリングしてくれるのだが、位置が割と狭くてやりづらい。

大きな欠点だった「等幅フォントにデュアルスペースフォントが設定できない」は、spacing >= 90にするのではなく、spacingを無視するオプションを加えて対応している。

うまく噛み合っていれば使いやすいのだが、噛み合わないことが多いKDE Plasma。 状況がハマれば使いやすいため、私はラップトップではKDE Plasmaを使用している。

なお、KWalletでブラウザの鍵を管理すると、ブラウザはこれまで管理していた鍵を捨ててしまう。 逆にブラウザに管理させるとKWalletで使えなくなる。だから他のデスクトップと行ったりきたりするのには最大の障壁になる。

systray問題として深刻だったsniについても、現在はおよそ問題のない状態になっているようだ。

特にスケーリングの自由度は大きなメリットと言っていいだろう。 電源管理の柔軟さと併せて最新のラップトップには適しているように感じる。

KDE4時代の癖のあった特徴的な機能は下げられている。そのため、積極的にKDE Plasma workspaceを使う理由を損ねたという印象もある。

相変わらずbuggyな部分も残念だ。Balooは非常に振る舞いに問題があり、オフにしておくのが無難だろう。

XFce4

良い点

  • Alt+左ドラッグとAlt+右ドラッグに対応
  • パネルウィジットのアプリケーションメニューが独自メニューを設定できるため、引き出しとして使用できる
  • 「ランチャー」ウィジットは副項目を設定でき、やっぱり引き出しとして使用できる
  • XFce4 Terminalの使い勝手が良い
  • やたら積極的で便利な「透明度」設定。透明ウィンドウ好きにはたまらない
  • ThunarがSFTPに対応している
  • ディスプレイの「ブランクスクリーン化」と「電源off」が分けられていて、DPプラグアンドプレイに悩まされている場合は便利
  • 自動起動にそれとわかるように他のデスクトップ環境のものが選択できるようになっており、Gnome Keyring SSH Agentを使うということもできる
  • 8方向タイル可能。ただしタイルのショートカットキーは全く設定されていない
  • デスクトップ右クリックでデスクトップコンテキスト(アプリケーションメニューつき)、中クリックでウィンドウリストと結構便利
  • アプリケーションファインダーがコマンド実行で候補検索を含み、展開すると(Alt+F3でこの状態でスタート)メニュー検索もできるようになった
  • Whiskerは簡単にリサイズできる
  • Mugshotが実は結構便利
  • デスクトップにウィンドウリストを表示することもできる
  • ウィンドウスイッチャがグリッド状に表示されるため選びやすい
  • パネルの設定が器用で、高さを含めるかどうか、ホバー時で透明度を変えるか、隠すかなど設定可能。「Dock風」と「タスクバー風」を使い分けられる仕様
  • 壁紙の設定がモニターごとである上、「設定ダイアログをモニター上に動かせばそのモニターが設定できる」親切設計

悪い点

  • アイコンラベルのサイズは固定で、アイコンの間隔も固定。ちょっと長い名前のフォルダは簡単に隠されてしまうし、隠されないように設定すると
  • Bluemanが初回起動時だけXDGディレクトリを拾うため、XDGディレクトリを変更すると毎回エラーを出す
  • ウィンドウフィッティングは一応存在し、リサイズ時にも効くのだが、非常に弱い。設定もできない
  • 通知がいくつでも出してしまう上に、閉じても表示した位置に表示しっぱなしで大量に出されるととても困る
  • ウィンドウタイリング後にウィンドウを移動すると、ステートはタイルされていないことになるが、元のサイズには戻らない
  • パネルがデスクトップの大きさとして除外されない(xfwm4は除外できる)ので、デスクトップアイコンやConkyがかぶる
  • ファイル選択ダイアログがGnomeと同じものになったため、ファイルをパスで一気に入力することができなくなった
  • アプリケーションファインダーがフォーカスロックしないため、複数起動してしまうこともでき、さらにフォーカスを失うことがあるため「あれっ」となって複数起動してゴミが残ることが多々ある
  • フルスクリーンにしているとき、フォーカスしているアプリ以外はパネルがウィンドウより前にきてしまう (マルチヘッドディスプレイでのみ発生する)
  • 標準のボリュームアプレットがない (外部プログラムとしてはPulseAudioアプレットがある)

補足

XFce4になったときからずっと「ちょっとずれてる」「いい感じなのに、対応したにもかかわらず痒いところに手が届かない」を続けているXFce。

だが、Gtk3化の過程で大胆にチェンジした。 アイコンラベルとか、アプリケーションファインダーのフォーカスとか、微妙に「XFceだなぁ」と思うところは残っているものの、機能的には遜色ないどころか、他の環境を凌駕するところまで到達している。

Manjaroでは18.2からついにXFce4 Gtk3がメインになった。 使い物にならなかった時期が長かっただけに、ようやくという感じだ。 だが、

  • thunar-archive-plugin
  • thunar-volman

についてはGtk2を引き続き標準としている。 thunar-volman-gtk3はextraとcommunityそれぞれにバージョン違いがあるちょっと困った状態だ。

ウィンドウデコレータがMetacity相当になり、Cinnamonと同じものを使えるようになった。 今までちょっと偏りがあって使いにくいものが多かったので、非常によくなったし、デフォルトのものが結構スタイリッシュにもなった。

基本的な方向性はCinnamonやMATEに近い進化だと思う。 使い勝手が劇的に向上し、他のデスクトップと比べ見劣りするという印象を払拭した。 Gtk3になったため「軽い」という特徴は損なわれたが、最近はアプリケーションのほうが重く、Gtk2を採用するアプリケーションも少ないため、正直デスクトップの重さというのはそもそも感じにくい。 むしろ処理が速くなって快適になったくらいだ。

LinuxでNvidiaもIntelもおかしなことになっているのでRadeonにかえてみた

もういやだ

パワフルなThinkStation P720ワークステーションだが、最近様子がおかしい。 Nvidiaではおなじみの

  • 画面が点滅する
  • X11 APIでスクリーンキャストするとウィンドウが消えてしまう (だからスクリーンショットでもウィンドウが消える)

という問題は直る気配がない…どころか、従来はVblankとFlippingを禁止すれば抑制できたのだが、最近はダメだ。 さらにいえば、Nvidia固有だったこの問題は、最近ではIntelでも発生する、というかINtelのほうがひどくなっている。

そして、追加で

  • Libreofficeが使っているSAL PLUGINとglibの連携が腐ってしまって、ほとんど操作不能なレベルでフリーズする
  • Vivaldiでありとあらゆる操作においてフリーズする

という問題が追加された。 Libreofficeの問題は最初Nvidiaだけだったが、現在はIntelでも発生するし、SAL_USE_VCLPLUGIN=genで防げたのだが、現在はこれも無理である。

そして、4kディスプレイにしてからビデオメモリが足りないのか、ウィンドウを開いていくとウィンドウ領域がグリッド状に表示され、かすかにウィンドウが見える場合もあるがほとんどの場合見えず、操作もできないという状態になる、ということに悩まされた。 作業効率が恐ろしく悪いことになってしまうため、毎日とてもストレスだし、貴重な時間を、1日で1-2時間程度失っている状態だった。

もうこれは耐えられない。

一方、Godavariはこのような問題を発生しない。 「じゃあGodavariでやれよ」と思うかもしれないが、Godavariは全面的にとっても非力である。よく馬鹿にされるくらいには。

それで、現在の出費は痛いし、TSMCは7mmプロセッサを控えている状態だというのはわかっているが、 結局のところRadeon 3000シリーズは噂の域を出ないということも踏まえて、思い切ってRadeon RX580を購入することにした。

なぜRX580か

最大の理由はLinuxにおけるパフォーマンスである。

WindowsにおいてはVega RXもそれなりの性能を示すようだが、Linuxにおいては多くの場合Vega RXとの性能差は誤差の範疇に留まる。 Vega RXでもGTX1060は越えない、というような所ぅたいだ。

にもかかわらずVega RXはずっと高値を維持しており、相当にコストパフォーマンスが悪い。 しかも、Vega RXはNvidiaと比べても相当燃費が悪いようで、「電気をめちゃくちゃ食う」のである。

そもそも私のP720はQuadro P6000のSLIを想定しているためキャパシティとしては耐えられないこともないのだが、家の電気回線はそうではないし、 無駄な電気は使いたくない。

また、Vega RXのパフォーマンスはVega RX 64であっても「Nvidia GTX1070に届かない程度」というのがWindowsにおいても現実であるようで、 ゲームのことを考えて高性能なカードを選ぶ、という気にもなれなかった。

タイミングは悪いなぁ、やたら高いなぁと思いつつも、Linuxにおいてはベストな選択肢となりそうなRX580を選択したということだ。

製品はAMD専門メーカーSapphireのゲーミング向けNITRO+シリーズSA-RX580-8GDN+001V2 VD6801を選択した。 オーバークロック製品で、発熱量は多いが性能は高いようだ。

P720にSapphire NITRO+ RX580は「ギリギリ入る」

製品が届いてびっくりした。 「大きい」

いやもう、比べるのが無意味なぐらい大きい。 「ミドルクラスだし、GTX960と同じくらいだろう」とか思ってサイズのことは一切気にしなかったのだが、「これはやばいかもしれない」と感じるほど大きかった。 ゲーミング向けトップモデルはこれより大きいのか!?

入らないかもしれない、と懸念したが、結局はギリギリながら収まった。 上下とも入るが、下段に関しては電源配線に触れてしまう。 また、サイドパネルに接触するため、サイドパネルがしめづらくなる。

「普通に入る」とは言い難い、「かろうじて入った」である。 だが、入る。

なお、SA-RX580-8GDN+001V2は補助電源が8ピン+6ピンというGTX1080Ti並の要求で、P720の標準の補助電源は2本であるためこれを全部使ってしまい、SLI構成はできない。 汎用の拡張コネクタがあるのだが、こちらは専用品で、なおかつLenovoとして単体の販売はしていないので、Crossfire構成にしたい場合は予めP6000のような「補助電源を2つ使う」ビデオカードを2枚構成にしておく必要がある。

クーリングパイプがまるでインテークマニホールドのようで、さらにSAPPHIREのロゴが青く輝き、大変かっこいい。 まぁ、P720の場合サイドパネルが透明なわけでもないので、全く見えないが。

消費電力は

4114+Quadro P400構成と比較すると、アイドル時で107Wと、約60W増えた。 運用時も140から220Wで、60W増加と見ていいだろう。 ただし、変動しやすくなったため、平均すると80W増加とみたほうがいいかもしれない。

ただし、変動しやすくなったのは、「今までP400で処理しきれなかった分を即座に処理する瞬発力があるため」と見ることができ、効率的には変わっていないかもしれない。

「省電力」という印象はなくなってしまったが、性能を考えればまぁ想定通りといったところ。

問題は解消したか

ほぼyesである。

  • 画面の点滅はなくなった。代わりにログイン時に画面がおかしくなることがあるが、支障は実際にはない
  • スクリーンショット、及びスクリーンキャスティングでウィンドウが消える不具合はなくなった
  • Libreofficeがフリーズする問題は解消された
  • Vivaldiが異様にフリーズするという問題は 軽減された
  • ウィンドウが表示できなくなる問題は解消された

また、私が非常に不満としていた、私お気に入りのフラゲ1が重すぎるという問題が事実上解消された。

この問題自体はつい先日からChromiumがマルチスレッドでFlashを処理してくれるようになり、最大で12.5%(5スレッド)で処理してくれるためにかなり軽減されてはいたのだが、 ビデオ描画のもたつきがなくなったためか、全く支障なくなった。 不思議なものだ。 まぁ、Flashはビデオアクセラレーションの対象ではあるのだが。

ちなみに、このゲームがあまりにも重いのは「4114が非力で、うち特有の問題」と考えていたのだが、先日Thinkpad X1でやってみたところ、とてもプレイできないくらい重かった。 というわけで、むしろ「このハイパフォーマンスマシンですらもこの程度」という状態だったと考えられる。 恐らくはWindowsであれば支障ないのだろう。

Vivaldiの重さはどこから

RX580になってVivaldiが操作のたびに、あるいはフォーカスするたびに止まる (タブ=レンダリングプロセスが止まるのではなく、Vivaldi全体が止まる)という問題は解消された。

ちなみに、Intelはこの問題はより深刻で、Vivaldiを立ち上げたあとメニュー操作をするとウィンドウマネージャごと固まってしまう。

だが、依然としてふたつの問題がある。

ひとつは、右クリックでメニューを開くとかなり長い時間固まるということだ。 これはstraceしてみると

read(17, "!", 2)                        = 1
write(18, "!", 1)                       = 1
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
munmap(0x7fc6fd5f7000, 8832)            = 0
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
munmap(0x7fc6fd5f7000, 8832)            = 0
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
munmap(0x7fc6fd5f7000, 8832)            = 0
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
munmap(0x7fc6fd5f7000, 8832)            = 0
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
munmap(0x7fc6fd5f7000, 8832)            = 0
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
munmap(0x7fc6fd5f7000, 8832)            = 0
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
munmap(0x7fc6fd5f7000, 8832)            = 0
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/DeletedManjaro/UmePlus/umeplus-p-gothic.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/DejaVuSans.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Monospace/font-bh-ttf-1.0.3/luxisr.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/gsfonts/NimbusSans-Regular.otf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/MuktiNarrow.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/malayalam.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/Sampige.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/padmaa-Medium-0.5.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/VL-Gothic-Regular.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/OTF/ipag.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/TSCu_Paranar.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/NanumGothic.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Korean/UnDotumBold.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Commercial/Unknown/CODE2000.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Morisawa/\343\203\222\343\203\251\343\202\256\343\203\216\344\270\270\343\202\264 Pr6N W4.otf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Morisawa/\343\203\222\343\203\251\343\202\256\343\203\216\344\270\270\343\202\264 Upr W4.otf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/Mathematica6.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/Mathematica7.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/AndikaRegular.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Japanese/Tsuyuzora-bunko/XZBB.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Japanese/WadaLab/wlcmaru2004aribu4430/wlcmaru2004aribu.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/OTF/FiraSans-Regular.otf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Japanese/nukamiso/nukamiso_yamiyootf_beta07.otf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/OTF/Vollkorn-Regular.otf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/Ricty-Regular.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Commercial/Motoya/NFbc1kp.ttc", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Japanese/Motoya/MTLc3m.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Japanese/tfont/TGothic-GT01.ttc", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Japanese/UchidaAkira/OradanoGSRR.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0

という感じで、フォントを片っ端から読んでいて、ものすごく時間がかかっている感じだ。 ちなみに、これはChromiumだと起動時に発生するため、フォント数が増えるとChromiumは起動が遅くなるのだが、Vivaldiではコンテキストメニューの表示がすさまじく遅くなる。 また、この問題はフォームをクリックしたときに発生するため、非常にストレスになっている。

もうひとつはページをロードしたときにロードの途中で異様に時間がかかる。 これはstraceを見ても止まるわけではないのだが、特徴的な要素は見つからず、コンソールで見るとただ単に飛んでいる。 これはChromiumでも発生するため、恐らくBlinkの問題だ。

Vivladi固有の問題のほうは時間があるときに報告するつもりだ。

現状では「Firefoxを使う」というのが解決策になりそうだ。 Chromiumは最近とにかく重くなっている。CPUの使い方がえぐいし、異様に処理に時間がかかるようになった。 フリーズしている、と感じるような処理時間で、原因がよくわからないケースが多い。 これがバージョン71から発生していることは認識しているのだが、そもそも「ウェブレンダリングを難しくしすぎている」というのが問題で、 「なんでもかんでもウェブでやろうとするのやめてくれないかなぁ」と心底思う。

だいたいこの流れや、レンダリングエンジンの複雑さがGoogleの胸先三寸になってしまっていることにはとても気持ち悪さを感じている。

Radeon RX580はどうだったか

なお、RTX2000シリーズは通常利用での暴走や出火などが問題視されていることからあまり完成度は高くないと見られており、 AMDは14nmプロセスでNvidiaより圧倒的に性能が低く、それでありながらライバルと位置づけるNvidia製品よりもずっと高い、という状況である。 しかもTSMCは7nmプロセスの新しいカードを用意しており、Radeon VIIという新製品は「RTX2080相当の性能で、価格的にも同等。Vega RX 64比では性能は1.8倍」とのたまっている。 TSMC、及びAMDは7nmで攻勢をかけるつもりのようで、とにかく時期が悪いのは確かだ。

だから、今買うならGTX1080かRTX2070あたりが妥当な判断で、RX580が4万円程度はするという点を考えると普通の(Windowsの、ゲーマーの)ユーザーには「迷わず買う人以外は買わないほうがいい」レベルの製品だろうとは思う。

Linuxにおける性能は、おおよそWindowsにおけるGeForceとの関係と同等。 つまり、NvidiaがWindowsと比べて半分程度の性能しか出せていない以上、AMDのドライバもWindows版と比べて半分程度、と考えれば良いのではないだろうか。 以前はもっともっと差が開いていたのでだいぶ健闘しているといって良さそうだ。現在はNvidiaのプロプライエタリドライバとAMDのオープンソースドライバ(AMDGPU)は同等の出来ということになる。 性能面では、だが

ゲーミング部分で言うと、ドライバの出来と、ゲームにおける最適化の結果として圧倒的にGeForce寄りであり、Radeonはその力を発揮できないという状態が続いている。 だから、ゲーム用途では何も考えずにGeForceでいいというレベルだし、多分それはRadeon VIIが出ても変わらない。

一方、Linuxのワークステーションユースで不満が出るという気はしなかった。 vdpauinfoでは

display: :0   screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name   width height types
-------------------------------------------
420    16384 16384  NV12 YV12 
422    16384 16384  UYVY YUYV 
444    16384 16384  Y8U8V8A8 V8U8Y8A8 

Decoder capabilities:

name                        level macbs width height
----------------------------------------------------
MPEG1                          --- not supported ---
MPEG2_SIMPLE                    3 65536  4096  4096
MPEG2_MAIN                      3 65536  4096  4096
H264_BASELINE                  52 65536  4096  4096
H264_MAIN                      52 65536  4096  4096
H264_HIGH                      52 65536  4096  4096
VC1_SIMPLE                      1 65536  4096  4096
VC1_MAIN                        2 65536  4096  4096
VC1_ADVANCED                    4 65536  4096  4096
MPEG4_PART2_SP                  3 65536  4096  4096
MPEG4_PART2_ASP                 5 65536  4096  4096
DIVX4_QMOBILE                  --- not supported ---
DIVX4_MOBILE                   --- not supported ---
DIVX4_HOME_THEATER             --- not supported ---
DIVX4_HD_1080P                 --- not supported ---
DIVX5_QMOBILE                  --- not supported ---
DIVX5_MOBILE                   --- not supported ---
DIVX5_HOME_THEATER             --- not supported ---
DIVX5_HD_1080P                 --- not supported ---
H264_CONSTRAINED_BASELINE       0 65536  4096  4096
H264_EXTENDED                  --- not supported ---
H264_PROGRESSIVE_HIGH          --- not supported ---
H264_CONSTRAINED_HIGH          --- not supported ---
H264_HIGH_444_PREDICTIVE       --- not supported ---
HEVC_MAIN                      186 65536  4096  4096
HEVC_MAIN_10                   186 65536  4096  4096
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8         16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8 
R8G8B8A8         16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8 
R10G10B10A2      16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8 
B10G10R10A2      16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8 

Bitmap surface:

name              width height
------------------------------
B8G8R8A8         16384 16384
R8G8B8A8         16384 16384
R10G10B10A2      16384 16384
B10G10R10A2      16384 16384
A8               16384 16384

Video mixer:

feature name                    sup
------------------------------------
DEINTERLACE_TEMPORAL             y
DEINTERLACE_TEMPORAL_SPATIAL     -
INVERSE_TELECINE                 -
NOISE_REDUCTION                  y
SHARPNESS                        y
LUMA_KEY                         y
HIGH QUALITY SCALING - L1        y
HIGH QUALITY SCALING - L2        -
HIGH QUALITY SCALING - L3        -
HIGH QUALITY SCALING - L4        -
HIGH QUALITY SCALING - L5        -
HIGH QUALITY SCALING - L6        -
HIGH QUALITY SCALING - L7        -
HIGH QUALITY SCALING - L8        -
HIGH QUALITY SCALING - L9        -

parameter name                  sup      min      max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH              y        48     4096
VIDEO_SURFACE_HEIGHT             y        48     4096
CHROMA_TYPE                      y  
LAYERS                           y         0        4

attribute name                  sup      min      max
-----------------------------------------------------
BACKGROUND_COLOR                 y  
CSC_MATRIX                       y  
NOISE_REDUCTION_LEVEL            y      0.00     1.00
SHARPNESS_LEVEL                  y     -1.00     1.00
LUMA_KEY_MIN_LUMA                y  
LUMA_KEY_MAX_LUMA                y  

また、vainfoは

vainfo: VA-API version: 1.3 (libva 2.3.0)
vainfo: Driver version: Mesa Gallium driver 18.3.1 for Radeon RX 580 Series (POLARIS10, DRM 3.27.0, 4.20.1-1-MANJARO, LLVM 7.0.0)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

と当初対応しておらず、重大な弱点であった「H.265の非対応」は解消されているようだ。 (ただし、VP8/9には対応していない)

実際に試してみたところ、hevc_vaapiでのエンコードは116fpsと、P400でのNVENCには劣るもののかなりの優秀さを見せた。これだけ速ければ十分に実用的だろう。 画質がNVENCだと実用には厳しいところがあったのだが、VCEの場合いくらか画質がいいためより実用しやすい。 それでも、利用できる場合は「普通は画質を少しでも良く保存したい」ために「速さ優先」とはなりづらく限定的だが。

さらにNvidiaと違い、Waylandのコンポジターがちゃんと動作するというのも大きなメリットだろう。

消費電力的にも、あまり電気を使わないプロセッサを使っているからという事情が前提になってしまってはいるものの、使いづらくなるほどではない。 気持ちとしては「もっと消費電力が少なかったらなぁ」というのと、「2万円台前半だったらなぁ」という気持ちはとてもしてしまうのだが、そうした点を除けば「入れておけばとりあえず安心できるカード」であると言えるだろう。 「とりあえず入れる」には巨大すぎて入れるケースを随分選ぶが。

DVI-Dがひとつ、HDMIとDPがふたつずつで計5出力というところも、使いやすく不満になりにくい。 このビデオカードは大きさ的にも電力的にもそう来やすく選べるものではないが、Linuxでのグラフィックにまつわる不満を感じているのなら、RX580と言わずとも(例えば560でも)Radeonにする価値はありそうだ。

将来的には

「ゲームをする事情」と「デスクトップユースとして普通のアプリを動かす事情」は似ているのだが、「計算力を求める事情」と「Linuxにおいて快適な仕様」とは大きな違いが出てきている。

だから、贅沢を言えば2種類の仕様を用意できると最善で、贅沢を言えば、 「Ryzen + GeForce (主にWindows及びゲーム向け)」と「Ryzen Threadripper + Radeon (Linux及び計算向け)」の2台で編成できたらなぁ、と思う。 Zen2でこれを構成するのはなかなかドリーミーだ。

とはいえ、現実的に1台に絞るとしたら、「Ryzen + Radeon」という構成で「現実的な計算力とLinuxで扱いやすいグラフィック」というのを取るだろう。

現状、P720はどうなのかというと、やはり4114に求めたものと諦めていたものというのが大きい。

「メニーコア」という性能は、それを発揮する場面というのは本当に少ない。 実際、私の普段の運用では4114ですら持て余し気味である。 ところが、普段遣いではあらゆるアプリで処理性能が足りずストレスフルである。 「普通の使い方でモバイルi3程度の快適性しか求められない」というのはわかっていたが、それでもこのマシンのクラスを考えるととても残念な感じがする。

対して、実際にメニーコアを求めるケースでは4114では全然足りないのだが、それでも処理性能はi7とは段違いであった。 「4114はフルコアを活用できたとしてもi7に劣る」と考えていたが、実際は第8世代Core i7よりもずっと高速に動作した。 シングルコア性能も諦めていたほどに低くはなく、「さすがにそれなりに性能はある」と感じることができる。 そもそも、20コア40スレッドであるから、「20スレッドスケールテスト」が手元でできるというのもかなりのメリットだった。 だから、ちゃんと求めたものは実現できているし、価格を考えれば完全に目的を達成できるほどではないというのはわかっていた。

だが、結局のところ現状P720の最大の魅力は「省電力」である。 48Wから90W程度でありながら非常に優れた処理性能を発揮する、というのはかなり魅力的だ。

だが、やっぱりコンピュータは「性能が足りるか否か」であり、エクスペリエンスが良いかと聞かれるとYESとは答えがたい。 部分的にボトルネックになるブラウジングが全体の作業の足を引っ張るという状況も痛い。

「エクスペリエンスは諦めて処理量を増やしたい」というのとは矛盾しているのだが、やはりエクスペリエンスを優先したい気持ちが湧いてくる。 今回RX580にしたことで飛躍的にエクスペリエンスが向上したことも大きな理由になっている。 というより、RX580にしたことでP720がとりあえず不満ないくらいの動作をしてくれるようになった。 だから、バランス的には今の状態は悪くないのかもしれない。

Erina/Surtrに関する研究が一区切りついて、あまりデータプロセッシングすることがなくなったというのも大きい。 圧倒的に重い処理であったことから、これのためにメニーコアを求めたし、それによって成果も挙げたのだが、これがなくなると相当頻繁に回されるタスクを考えても実際8コアもあればあまり支障はなく、16コアのRyzenが用意されるのであれば不満はなさそうに思える。

ただ、ゲームをすることに関していえばGeForce優位は揺るぎそうにもないし、かといってLinuxでは現状NvidiaもIntelもなかなかの惨状ということを考えればRadeon以外選択肢はないという状態であり、 これが2台構成を求める理由ともなっているが、1台を選ぶのであればLinuxエクスペリエンスを優先することになるだろう。

ただ、Zen2の世代ではまだP720は現役で、しかも「非常に高機能で並列処理能力は高いが、通常の使い方ではそれほど性能は高くなく、消費電力はやや少なめで、筐体はとても大きい」マシンをメイン以外で使うというのは非常に難しい。 今Godavariがそうであるように、「主にWindows環境(音楽制作)、必要なときは計算資源または分離された帯域としてのLinux」みたいな使い方になるだろうか。 実際、音楽制作では機材がIntelプロセッサを想定したドライバでAMDドライバだといまいちうまく動かないケースもあり、現在のP720のような構成は非常に好ましい。 多くのVSTプラグインを使う場合も4114はかなり良い働きをしてくれる。 それでも、なんとも微妙な話で、Zen2世代でメイン機の差し替えを行うかは悩ましいところではある。

やはり「それぞれの用途で最適化した理想の2台」なんて夢見がちな話をするに留めるとして、多分本当に多くの人にとって有益なのは現時点で性能的にやや微妙な立ち位置にあるRyzen Gが不満のない性能まで引き上げられること、 あるいはRX 580相当のRadeonがもっと安く、省電力でコンパクトなものとして出てくることだろう。それは、次の世代で実現するかもしれないし、Zen3の世代まで待たねばならないかもしれない。

一方、X11はいよいよ限界を迎えている感もあるが、一方でWaylandがよくなっているわけでもない。 IntelもNvidiaも不具合が出る状態が続けばかなり苦しいことになるだろう。


  1. 具体的にはFlower Knight Girlである。 なお、 18禁バージョンもあるため 検索される際にはくれぐれも留意願いたい。

「ZshからRubyにしたら速くなる」 その理由とテクニック

現在取り組んでいるプロジェクトで、パフォーマンスチューニングの一環として当初Zshで書かれていたスクリプトをRubyで書き直すことによって、60倍程度の高速化を実現した。 もちろん、単純に書き換えただけではなく、可能な限りfork/execをしないようにしたり、コストがかかる処理を最小にするなどの工夫を伴って手に入れた結果だが、「ZshでしていたことをRubyに書き換えた」だけでも相当な効果があった。

このパフォーマンスチューニングは単にプログラムを書くだけの人には生まれにくい発想である。 Unix、そしてLinuxのシステムや、プログラミング言語処理系に関する知識がないと考えられない要素が多いのだ。

そこで、この話を解説する。

「ZshよりRubyが速い」そのわけ

根本的な話として、Zshはそもそも遅い処理系だ。 「Zshが遅い」という話はZshのメーリングリストでもちらほら話をされる。 別にBashと比べて遅いということではないのだが(Bashもまた非常に遅い処理系だからだ)、状況によっては速度が問題になる程度に遅い。

Rubyも相当に遅い処理系であると言われていたし、実際かなり遅かったのは事実だ。 それでもZshに比べれば随分早かったのだが。

だが、それ以降、Rubyは高速化に取り組み続けている。対して、Zshはあまり高速化には取り組んでいない。だから、差が開いている。

しかし、理由がそれだけというわけではない。

Zshは純粋なインタープリタである。対して、Rubyはスクリプト言語ではあるがバイトコードインタプリタ型である。 この違いは、syntax errorが起きるタイミングが、Rubyがスクリプトを実行しようとしたタイミングであるのに対し、Zshはその行に到達したときであることからもわかる。

インタープリタ型であれコンパイラ型であれ、ソースコードを機械語に変換しなければならない、という点は変わらない。 その違いは方法とタイミングである。

インタープリタ型言語の場合、「1行ずつ(1コマンドずつ)変換する」のである。 その変換方法はもちろん処理系によって異なるのだが、Zshの場合、complex commandでも複数の文をまとめて変換することはしないし、ループによって繰り返される場合でも一度変換したものを使いまわしたりはしない。

対してRubyは、最初にコード全体を構文木に変換する。 RUby 1.8までは構文木インタープリタによってこれを実行していたが、Ruby 1.9以降はこれをさらにバイトコードに変換し、バイトコードインタープリタ(VM)によって実行するようになった。 バイトコードはRuby専用の機械語のようなもので、VMによって非常に小さなコストで実行できる。 Ruby 2.6からはJITコンパイラも追加され、部分的にCコードを生成し、これをネイティブコンパイラ(例えばgcc)によってバイナリコードに変換する(こともできる)。

これで1行だけのようなコードだとあまり差は出ないし、Zshでは1行だけどRubyでは何十行という可能性もあるので、このようなケースではRuby有利というわけではなくなる。 だが、ループで何度も同じコードを実行するような場合には非常に大きな差になってくる。 今回の場合、テスト段階で500回のループであったことから、大きな差になったということである。 だからループ回数が増えると倍率的にも速度差はさらに開く。

fork/execとコンパイルにかかる時間

Unix関連に少し知識がある人であれば、「forkはコストが重く遅い」というのを聞いたことがあると思う。

だが、この認識にはちょっと注意が必要だ。 というのも、C言語の速度から見た時に「forkする時間があればどれだけ実行できるか」という点を考えるとsystemで外部コマンドを呼び出すとそこだけ局所的に時間がかかる、という状況が発生する。

だが、実際にはfork(2)しても1000分の数秒にすぎない。 どちらかといえばそれよりもexec(2)のほうが重いのだが、それでもせいぜい100分の1秒程度だ。 だから、C言語で書いている場合ですらそれなりに長くなる場合はむしろ実行コストを省略できてコマンドを呼び出すほうが速かったりする。

昔のUnixではfork(2)はもっともっと遅かった。 現在のLinuxにおいてfork(2)が速くなったのはコピーオンライト形式であることの恩恵が大きい。 古典的なUnixではfork(2)は呼び出した時点でプロセスのメモリをコピーしていた。直後にexec(2)する場合はコピーしたメモリの内容は全く使わないのでかなりの無駄だ。

ところが、現在のLinuxにおいてはfork(2)によってメモリはコピーされない。共有されるのである。 そしてforkされたプロセスが共有されているメモリに対して書き込みを行った時に別に領域を確保してそれを変更する仕組みだ。

結果的にfork自体は一瞬に近くなっている。

そして、もうひとつ重要なのが「コンパイル時間」だ。 Rubyは起動時に対象スクリプトの変換を行う。 だが、この変換コストは速くなるに従って増加している。以前は構文木に変換するだけだったのが、1.9からはさらにバイトコードに変換する時間が必要になったし、2.6でJITを使うとさらにCコードを生成してそれをコンパイルする時間まで必要になっている。 つまり、Rubyはだんだん「実行は速くなっているが、実行に着手するまでは時間がかかるようになっている」のである。

これは、例えばechoであれば

% time /bin/echo > /dev/null
/bin/echo > /dev/null  0.00s user 0.00s system 79% cpu 0.001 total

ということになるのだが、Rubyだと空っぽに近くても

% time ruby -e 'nil'         
ruby -e 'nil'  0.04s user 0.02s system 59% cpu 0.089 total

結構時間がかかる。 つまり、一瞬で実行が終わるRubyスクリプトを何度も何度も繰り返して呼び出すと、トータルではかなり時間がかかるわけだ。 もともとのスクリプトは本体はRubyで、呼び出しがZshだったので、20並列で各500回、Rubyによるコンパイルがかかっていた。だから、かなりの時間がかかっていたのだ。

だが、「Linuxのforkはメモリが共有され、ほとんど一瞬で終わる」という点を利用すると改善の余地がある。 それは、実行可能なRubyスクリプトをライブラリ化する、という方法だ。

ZshからRubyを呼び出す場合、どうしてもRubyを呼び出すたびにRubyによるコンパイルをかけざるをえない。 当初は10000回コンパイルされていたのだが、500回のループをZshではなくRubyで行うようにすれば20回で済むようになる。だが、それでも20回のコンパイルが必要だ。

しかし、呼び出すスクリプト自体をRubyに変えてしまえば、実行しようとするスクリプトをライブラリとしてロードするという方法がとれるようになる。 ライブラリとしてロードすると、そのコンパイルは呼び出し元スクリプトをロードしたときに行われる。 もちろん、呼び出しの目的は呼び出すだけであり、直接そのライブラリの機能を使うわけではない。だが、この状態からforkすると、「コンパイル済みコードがメモリ上にあるRubyプロセス」が出来上がる。

この時点でスクリプトを実行する方法は「メソッドを呼び出す」(あるいは、その機能を果たすオブジェクトを作ってメソッドを呼び出す)だけである。 繰り返し呼び出すループを書くのも、単にRubyのループを書いて、そこで繰り返しメソッドを呼び出すなりオブジェクトを作るなりすれば良い。 呼び出し元スクリプト側では並列分だけforkしたあと、Process.waitallでもしていればいいわけだ。

これはZshに対して、「Rubyスクリプトのコンパイルが1度だけでいい」「execする必要がない」というメリットをもたらしている。 どちらも結構コストの高い処理であるから、繰り返し実行する場合は非常に大きなコストになり速度を低下させる。「処理自体は軽いのだが果てしなくループする」タイプのスクリプトに対してこの方法は本当に効く。 なぜならば、そのようなスクリプトに対してはコストの高い呼び出しをしているとコストのほとんどは呼び出しで占められ、実行コストは小さいためにスクリプト自体を高速化しようとがんばったところでほとんど無意味だし、逆に呼び出しコストを軽くすると劇的に速くなるからだ。

systemd-nspawnでManjaro LinuxからArch Linuxする

systemd nspawn

なんかSystemdを毛嫌いする人が多いのだけど、結構使いやすくて便利な機能が多いので、私は好きだ。Xサーバーみたいだと思う。

systemd-nspawnはcrgoupsを利用したLinuxコンテナである。 LXCよりもずっとシンプルな実装で、かつ簡単に使うことができる。 全然知られていないけど。

とりあえずArchする

Manjaroにもarch-install-scriptsがあるためpacstrapできたりする。 なので、初回インストール前には

# pacman -S arch-install-scripts

とやっておく。

そしたらコンテナを作る。 こちらは新規コンテナを作るときにやる作業。

# pacstrap -i -c ~/Container base base-devel

Arch Linuxをインストールしたことのある人ならわかると思うのだけど、 最低限baseがないと機能しない。そして、AURを利用する場合はbase-develも含んでおかないといけない。

あとはログインする。 これは、起動時に実行するもの。

# systemd-nspawn -b -D ~/Container

これでコンテナを起動することができる。終了する場合、コンテナ上で電源を切る。 終了は少し時間がかかる。

# poweroff

LXCと違って自動的にブリッジインターフェイスもセットアップされ、起動しただけでネットワークがちゃんと機能する状態になる。 LXCと比べても随分と話が早い。

ManjaroだとArchを構築するのは簡単だし、もちろんArchやAnterogosでも簡単だけど、そうでないディストリビューションがどうやってコンテナ上にOSをインストールするか、については各々調べて欲しい。 私はArchが使えれば満足なので、コンテナ上で他のディストリビューションを使おうとは思わないし、現状、Manjaro以外をホストにしようとも思わないからだ。

おまけ。この環境からPowerlevel9kするために

ちょっとつまずいたのでおまけ。 標準ロケールがen_US.utf8になっているため、Powerlevel9kのPowerline記号が出ない。

そこで、/etc/locale.genを編集してja_JP.UTF-8 UTF-8をアンコメントし、

# locale-gen

そして、/etc/locale.confを編集してLANGja_JP.UTF-8にしてから

# localectl set-locale LANG=ja_JP.UTF-8

これでちゃんとPowerlevel9kのアイコンが出るようになる。

Powerlevel9k * モリサワフォント

Zsh * Powerlevel9k を使っていて、なおかつモリサワパスポートユーザーである人なんて多分この世に数えるほどしかいないと思うので、需要は限りなく0に近い記事を書かせてもらうことにする。

Powerlevel9kで使われるU+F015(ホームマーク)やU+F17C(Linuxマーク)はPrivate Use(外字)領域であり、 文字として定義されていない。 そして、モリサワフォントはこの領域を使用しており、U+F015は「言信」という文字(実際は一文字)に割り当てられており、 モリサワフォントを導入するとAwesomeフォント(Nerd font)に優先されてしまうため、有効に機能せず、文字化けしてしまう。

解決方法は結構シンプルで、FontConfigで

のようにしてNerd fontをprependするだけである。

この問題のハマりポイントは、「Nerd fontのグリフを持っているCicaを指定したときにNerd fontグリフ部分を使ってもらえない」ことである。 だから、Cica一本に頼っていた場合はNerd Fontを別途導入する必要がある。

Zshでの連続的呼び出しに環境変数を使ってみる (Zshのガベージコレクション)

Zshは極めて強力なシェルだが、大規模プログラミングにおいて使われることは少ない。 だが、Orbital designにおいてはシェルスクリプトは強力な武器だ。できれば積極的に活用していきたい。 そうなると、Zshにおいて明らかでない、あるいは公知ではないことと付き合っていかなければならない。

単純に言えば今回は

のような処理を行うスクリプトを、invoke_workerがファイルを読み込むのではなく、事前に読み込んでおくことでワーカーの処理時間を短縮したいということだ。

のようにしたいということだ。

だが、問題は「これがメモリを食いつぶさないか」ということである。

意図と効果

普通のスクリプトの場合、この方法はほとんど効果をもたらさない。もしかしたらマイナスになるかもしれない。

そもそもこれらの情報が「単純にファイルとして読み込むだけ」の設計になっているところも工夫のなせる技なのだが、必ずしもそのようにできるわけではない。 特にクラスタ仕様になっているとファイルアクセスが遅いかもしれないし、その違いを吸収するためにさらに別の方法をとるかもしれないのだ。

ワーカーは起動数も多く、当然ながら処理としては重い。 逐次実行されるワーカー部分であまりその処理を担わせたくない。 特に設定のほうは起動される全てのワーカーにとって共通である。 これを環境変数にするメリットは大きい。

Linuxのfork(2)はコピーオンライトだ。 configは文字列であり、起動されるワーカーではその文字列をパースすることになるから、この$config環境変数が変更されることはない。 つまり、この環境変数は実体はひとつであり、常に同一の実体が参照される。コピーされることもないので速度が上がる。ディスクIOとメモリへのコピーが2回目以降省略できるのだ。

ただし、環境変数で渡す文字列は「システムコールがCライブラリである」ためにC文字列(の配列)であり、\000が含まれていると文字列がそこで終わってしまう。 私は勘違いと慎重さを欠いたことから赤っ恥をやらかしてしまった。

データのほうは、ほぼ単純に、ワーカー実行中に時間がかかる(かもしれない)データの取得を裏でやっておきたい、ということである。 これも環境変数にしてしまえばワーカーはリード時間をとられない。所要時間の総量は変わらないが、裏でやることで逐次実行部分に含めることを避けるということである。

問題と検証

だが、これは

というのが100万回実行されるということだ。 しかも、これはループのたびに異なる値になる。

もしZshにガベージコレクタがなければ100万件のデータを抱えてしまうことになり、これはメモリ消費量的にまずい。

というわけで、「Zshは変数を上書きしたらメモリを開放してくれる(ガベージコレクションしてくれる)のか?」という疑問を解き明かす必要ができた。

この調査は割と簡単で

とし、

のようにしてメモリ消費量を監視すれば良い。

ちなみに、100Mを指定しているが、/dev/urandomは一度に読めるのは32MiBまでである。

80340
215640
80332
80332
80348
43344
80340
80340
80332
80332
215636
80340
80332

だいたい2倍程度と見ていいと思うのだが、ときどき3.5倍程度まで増加する。 ただ、だいたい2倍ということはかなり迅速にメモリを回収してくれている印象だ。

しかし、実際のワーカーはこんなに長時間実行はしないので、実際のワーカーの実行時間に近い感じにしてみよう。

108932
80340
195300
80340
215628
80340
211472
111616
80332
178644
43344
215644

回収しきれないタイミングが増えてメモリ使用量にばらつきは生じているが、回収ペースを上回ってメモリ消費量が果てしなく増えていくようなことはないようだ。

結論

  • Zshにはガベージコレクタがある
  • Zshでパラメータを上書きすると、ローカル変数か環境変数かによらず迅速にメモリは解放される
  • IOコストが高いなどで逐次的に実行するコストを削減したい場合、コントローラで環境変数にする作戦はなかなか有効

追加の注意点

フルスケールするように設計されているワーカーの場合、CPUコア数を使い切るだけワーカーを起動していると、結果的に裏で色々するためのコンテキストスイッチコストが高くついて全体では遅くなる可能性もある。 というか、ワーカーの実行がそれほど時間のかからないものであるならばwaitの時間は短くなり、waitの時間が短くなるほどスケール阻害要素としては大きくなる。

エンジニア&ワナビーに贈る名著7選

はじめに

昔Twitterで似たようなタグがあったような気がするのだけど、 私はコンピュータ関連書籍(雑誌込み)には300万円くらいはつぎ込んでいるので、その中で「これは色褪せない、他にはない、素晴らしい!!」と思ったものを挙げたい。

私が今まで読んできた中でボロボロになるまで読んだ本たちだから、だいたいの本は古く、そして絶版・入手困難になってしまっている。

このほかにも見どころがあって、色褪せない本というのはあるのだが、今回は「名著」と言い切れるような必読書のみに絞って挙げてみた。

ハッカーズ大辞典

いわゆる「おもしろ用語集」のような本。

用語自体が技術的知識になる、という側面は少ないのだけれど、 昔のハッカーたちがどんな棋風で、どんな出来事で、どんなふうに接し、振る舞ってきたのかがわかる「文化本」という意味合いが大変に強い。 そして、ハッカーマインドを理解するにもこの本は欠かせない。

ここに登場する語のほとんどは現役ではなく、実際に使われることは多くはない。 だが、ハッカーは大概、この本のことは知っているし、ここに登場する用語や背景のことは知っている。 これらのことは元ネタである “Jargonfile” で呼ぶことが多いが、実際にはこの和訳本のことを示していることがほとんどである。 このJargonfileのオリジナルはインターネット上で読むことができるが、和訳も大変イケているので、ぜひ翻訳本をお勧めしたい。

だが、残念ながらこの本は絶版である。 改装版が出ていることを知らなくて、私は今でも探しているくらいだ。 (私は翻訳初版しか持っていない)

インターネットの起源

インターネットはどのように誕生し、どのような苦労があったのか、 そのときどのような信念があったのか、それを窺い知ることができる名著。 翻訳が少し雑なのが気になるが、貴重な当事者の証言である。

インターネット陰謀論を吐きたがる人には一度は読ませたい本だ。

こちらも絶版プレミアだが、Kindle版があるのが救い。

プログラミングPerl

「ラクダ本」といえばこの本。 Perlを学ぶ人だけでなく、プログラミングを学ぶ全ての人にとって一読の価値のある名著であり、特に正規表現を理解するには (オライリーの「正規表現」以上に)この本の助けが必要となるだろう。

PerlはCほど難解ではないが、隠しきれない低レベル感がある。 ひとつひとつの概念を丁寧に解説してくれるので、プログラミングについて理解する良い下地になる。 「書いてあることをそのまま実行する」ことに頭が行くタイプの人には向いていないだろうが、理解して地力を高めていくということが分かる人には地力育成法としてかなり良い本だと思う。

上下巻なのだが、VOLUME2はリファレンスであるため、「なくてもよい」感が強く、VOLUME2のほうは事実上の絶版。 VOLUME2の巻末の用語集は結構おもしろいのだが。

Perlクックブック 第2版 VOLUME1

Perlを実用的に活用するための本、なのだが、クックブックなので基本的にはテクニック集だと思えばいい。 だったらわざわざ挙げるほどではない、と思うかもしれないが、割とクックブックって良いものが少なくて、推挙できるのはこれぐらいのものだ。

このクックブックにはふたつの面がある。

ひとつは、ラクダ本で学ぶことができる基礎によって理解を深めても、実際になにかを実現しようと思ったときにどうすればそれが実現できるのかということを教えてくれる教科書としてだ。

そして、もうひとつはここに書かれていることを理解できるかどうかが、プログラミングに対する理解度をはかるものになるということだ。 小さな課題をテクニックを駆使して解決しているため、それによって解決できることはわかるのだが、レベルが十分に上がっていないとなぜそれによって解決できるのかがわからない。 読み物として読んだときにするっと理解できるようになったとき、自分のレベルが向上したことを実感できるだろう。

VOLUME2はPerlに特化した部分が多いので、VOLUME2はあまり必要ないかもしれない。 いずれにせよ絶版本で、入手は難しい。

Hacking:美しき策謀 第2版 ――脆弱性攻撃の理論と実際

誤解してほしくないのは、これによって攻撃ができるようになるような類の本ではない。 この本はそもそもかなり小さくて薄い本なので、そこまで充実の中身はないのだ。

だが、多くの人が「なんとなく言葉と、用語集の説明文程度で知っている」脆弱性攻撃の中身を、簡潔かつ的確に教えてくれる。 この知識は脆弱性攻撃のみに有効なわけではなく、コンピュータの低レイヤーを理解する補助教材としてかなり有効だ。 低レイヤーが苦手な私はこの本に随分助けられた。

ここで扱っている内容は非常に難易度が高く、実際に学ぼうとするとかなり困難を伴う。 もちろん、この本の記述範囲で理解できるはずもないのだが、なんとなく理解し、興味をもつには良いだろう。

新The UNIX Super Text 上 改定増補版,

私がLinuxをちゃんと学び直すときに使った教科書だ。

2003年刊行なのだが、内容は1997年のオリジナルからほとんど変わっていない。 結果的に、2003年時点でも大部分が「そのままは使えない」内容となっており、現在はそのまま使える知識などないに等しい。

だが、「何が基礎で、何が今につながり、それをどうすれば活用できるのか」ということを考えながら読むと、基礎を学ぶには最適なものになる。

実際、Mimir YokohamaのLinux基礎やコンピュータ基礎のカリキュラムづくりは、この本での内容をかなり参考にしている。 実際のところそのまま使える部分はほとんどなく、現代の技術に置換えただけで説明が完了するものもないため、流用できる内容はほとんどないのだが、どのようなことで構成し、何に触れるか、基礎としてどのようなことを学ぶことが地力の育成につながるか、ということを考える上で大変参考にさせていただいている。

この本の残念なところは、著者に一名、ちょっといい加減なことを偏見込みで書いている人がいることだろうか。

まつもとゆきひろ コードの世界‾スーパー・プログラマになる14の思考法

Ruby設計者のまつもとゆきひろさんの本。シリーズとして「コードの未来」「言語のしくみ」という本もあるのだけど、やはり名著といえばこの「コードの世界」だと思う。

技術書というよりは、文字通り「コードの世界」を紹介した本であり、特に難しいと感じる人の多いプログラミング言語にとっての文字コードの「内部コード」と「外部コード」の違い、正規表現エンジンの挙動と違い、並列実行などについてinsiderの視点で解説されており、楽しく読める上に読んでいるとプログラミングに関する理解も深まる。

「コードの未来」も併せて読みたい良書だが、こちらは技術を紹介する色合いが強いため、必読とまで勧められる感じではない。だが、お勧めではある。